Hello everyone,
I will be offline between Friday 18/1 and Tuesday 22/1. On Tuesday is
our regular bi-weekly call. I am not 100% sure that I can make it on
time. Would you like to have this call or should we reschedule?
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi,
Today I finshed an OIDC/SAML broker based on Satosa that I needed to patch for
[1] but also for not hashing the OIDC sub. It turned out the OIDC RP expected
the sub to map to pre-provisioned users, known by their SAML ePPN.
I even suspect it expected [2] but in absence of a configured claim in id_token
resorted to using the available sub.
The (hardcoded) fix is easy: just configure sub public and return value in
internal_data.py UserIdHasher::hash_data. Would there be any interrest in a PR
to make this an option in oidc frontend conf?
Then, I have two outstanding questions for IdPy. One is a formal answer to the
problem outlined in [1] and the second is [2]. We would really appreciate an
answer to both questions.
[1] https://lists.sunet.se/pipermail/idpy-discuss/2019-January/000339.html
[2] https://lists.sunet.se/pipermail/idpy-discuss/2018-December/000329.html
Best regards,
Martin
Hi,
Today I noticed a very strange behaviour of SATOSA SAML backend and was
curious if anyone on the list could shed a light on my findings?
For SURFnet's SecureID (2factor auth) service an SP needs to send a signed
authnRequest on the Redirect binding of the SSO endpoint. The only setting I
could find for SATOSA backend conf was
authn_requests_signed: true
This, however generates an enveloped signed xml messages that is dropped on
the Redirect endpoint, which is against the SAML standards, which explicitly
mandates the signature element to be removed and a URL request parameter
Signature to be added to the request:
3.4.4.1 DEFLATE Encoding
1. Any signature on the SAML protocol message, including the <ds:Signature>
XML element itself, MUST be removed
4. The signature value MUST be [...] included as a query string parameter
named Signature.
source: SAML-bindings-2.0-os
Did I miss something in the config to enable this behaviour or is pysaml2
blatantly ignoring the standard?
Best regards,
Martin van Es
Attending:
Heather, Scott, Christos, Ivan, Roland, Johan
Regrets:
Rainer
Notes:
0. Agenda bash
Heather will send out a new invitation with updated BlueJeans
information later today.
1. Project review
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Not a lot happened over the holidays. Ivan was working on items related
to eduTEAMS (common internal representations for back and front ends).
He also fixed some tests; we can now use the latest pytest.
Ivan archived the Satosa microservices repository; will move the issues
to the main Satosa repository. We will split out the microservices into
their own repositories (one for each microservice). This will allow for
a package per microservice, each with its own dependency. Ivan will send
email how core API should work with the microservices.
Ivan will go ahead and cut a release now that the microservices are set,
and then will work on the PR related to eduTEAMS. One PR in particular
relating to a discovery service; not quite sure what to do about this one.
Roland would still like to see an OIDC front and back end. That is on
the list; Ivan will reach out to Roland when that work is started.
Christos asks, regarding the consent service, do we know who is using it
and are there alternatives? When we discussed this in the past, there
weren’t many users of this service. The only ones actually using it were
SURFnet; they proposed to make a fork and maintain what they need. Main
repository has been abandoned. It would be good to find out if anyone
else is using it. eduTEAMS uses this for an information sharing service
since they base their access on Legitimate Interest, not a consent
capturing service.
- pySAML2 (https://github.com/IdentityPython/pysaml2)
A new pySAML2 will be coming out soon; this is related to a security
issue - see https://github.com/IdentityPython/pysaml2/issues/578
The issue is with how XMLsec does not check its data. When an error is
encountered with XMLsec, we need to add an exception in how that’s
handled. Ivan has made a few changes and created a test that shows some
errors we were missing when XMLsec threw an error.
Ivan has not pushed a final fix yet, but there are instructions on how
to work around this. Will push a small fix for now, and then we’ll
consider further changes to the code.
Johan has read the analysis and agrees this isn’t exploitable; that it
isn’t exploitable is only by luck.
Issue 579 relates to something reported out of eduTEAMS. This relates to
yet another issue - hw we define the digest and signing algorithm we
use. We need to make the default signing algorithm something other than
SHA1 and make that a choice in configuration.
- pyFF (https://github.com/IdentityPython/pyFF)
Leif is still working on refactoring the code. Need to get an update
from him out to the list.
How much will this refactoring change how the code is deployed today?
How will is relate to Satosa? The architecture is changing
significantly, but from the perspective of Satosa, nothing changes.
There will be an MDQ service available to get the metadata, and from a
discovery standpoint there will be a backend responding to requests and
you can run whatever front end you want (there will be a default
available).
- Governance docs (https://github.com/IdentityPython/Governance)
Board is meeting tomorrow; we hope to make more progress on deciding
about whether a CLA is required and the IPR home.
2. TIIME planning
- https://github.com/IdentityPython/Meetings/blob/master/TIIME-20190211
Note that Ivan will arrive about 11:30am (meeting officially starts at
11:00).
Current attendees: Ivan, Johan, Scott. Christos is tentative.
3. AOB
Hola a todos!
I've sent out the calendar invite to the usual suspects for the idpy
developers call. If you did not receive an invitation and want one,
please let me know.
-Heather
Hi Leif,
One of the features of pyFF that I am currently leveraging is the
ability to use different pipelines/configurations to offer multiple
discovery service "backends", each with its own set of IdPs.
This is important for a use case where a deployment supports multiple
VOs and each VO needs to have its own set of IdPs that are included in
discovery.
For example, with one VO a particular IdP from a commercial
pharmaceutical company should be included, but not for any other VOs.
Today pyFF supports this but I would like to understand if the upcoming
refactor (splitting off the discovery frontend into a separate project
and refactoring the backend) will change that.
I guess more generally it would be nice to better understand your
roadmap for pyFF development.
Thanks,
Scott K
Hi,
We are facing interesting OIDC challenges regarding sparsely featured OIDC
implementations.
One RP has an oAuth2 based implementation that never accesses the UserInfo
endpoint because (I freely quote the code comment) "They already have
everything they need to know from the id_token". It turns out, Google bloats
their id_token with claims so they reduce (effectively prevent) requests on the
UserInfo endpoint. It seems more and more RP's start to assume the token
endpoint will deliver everything they need or at least enough in the id_token.
We have decided to go along with the Googles of this planet and bend.
Now, pyop doesn't normally enrich the token endpoint id_token, but has a
parameter to consume extra_id_token_claims, just like the authhorizatoin
enpoint. From a satosa endpoint however, I have no access to the interal_resp
from the user to enrich the token endpoint. sastosa handle_authn_response does
set the authz database with the extra claims (consumed by userinfo endpoint I
guess) but I have no way to know the key (userid) to reliably access these
claims on the token endpoint and pyop doesn't have a authz code to userid
converter, as far as I know?
The best way I see, would be to modify pyop to enable internal (Provider
scope) extra_id_token_claims in the token endpoint. But we don't want to
maintain yet another fork in our deployment. This means that I'm allowed to
make a PR, but only if I have IdPy's commitment to merge the changes back
upstream.
Question: did I miss an option in pyop config that already does this? Or has
somebody already started an effort to implement this? If not: is IdPy willing
to merge this enhancement if I created a PR?
Best regards,
Martin
Attending:
Ivan, Heather, Roland, Rainer, Johan L, Scott, Martin
Regrets:
Christos
Notes:
0. Agenda bash
1. Governance update
Board meeting tomorrow, December 12. Main topic = IPR
2. PR review
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Ivan merged the nameID PR submitted by Scott today. Ivan is also
planning to do some more work on deprecating the internal hashing as
discussed on the last call. Will work on it today, and cut a release
that people can test.
Ivan met with Roland and discussed the new OIDC libraries. Ivan will be
working on a new pyOIDC frontend, which will be based on the OIDC
endpoint library that Roland developed. This should be fairly
straightforward. Will work on the backend at some future date.
Ivan met with Johan and Frederik around how we should evolve pySAML and
how we should integrate the new microservices style into Satosa. Ivan
will work on the plugin loader module, simplify it, and use that as a
custom solution to hook in the micro services. Will try to have this
before the TIIME meeting, and at the TIIME meeting we can package some
of the micro services.
- pySAML (https://github.com/IdentityPython/pysaml2)
Ivan spoke with Frederik and Johan about pySAML, how to refactor. Will
trace the big function calls and see what makes sense, then move the
lower functions into new modules and build up on them. Have functions do
one thing only, do that one thing well, then use them to build more
complex functions. There will be a transition period. Example: XML
signing of objects. (Every XML operation will be in its own module. )
See PR 498.
PR 483 - MDQ verification. Ivan did some small changes today and then
merged it. It may still needs tests; Scott to follow up.
Also fixed: a deprecation warning.
PR 577 - being able to return error codes not listed in the spec; they
should be implementation defined, but we weren’t following the spec.
Next items of work: PR 518 (day/times) and 498 (XML handling)
Next week, Ivan will be in Amsterdam to meet about eduTEAMS.
- pyFF (https://github.com/IdentityPython/pyFF)
Leif still working on this; summary of work is splitting the discovery
service from the persistence service. Is going ahead with the flask
redesign. Also looking at pyramid (another python framework). There will
be an API to talk to the backend persistence service, which can be
hosted separately from the front end discovery service. Will continue to
offer the MDQ service.
Scott is using multiple discovery services and thinks that the discrete
list of possible IdPs should be handled in the backend, not the front
end. Scott and Leif need to talk about this; Scott will send email and
cc the list. Rainer has a similar use case, where certain services have
additional IdPs that need to be shown to a certain number of users.
3. AOB
TIIME meeting - Monday, 11 February 2018 @ 11:00-17:30; will have a room
for 10 people
Next call, 8 January 2019
Hi Ivan,
Can you consider PR 483 for the next round of pysaml2 work?
It has been around for about a year. Without it SATOSA cannot check the
signature of a reply from an MDQ server, and since SATOSA is often
deployed with pyFF for its metadata source this leaves a significant
security hole unless the patch is carried along (which I am doing for a
number of deployments).
I have recently rebased the commit on master so it should not be a lot
of work to merge it.
If you find something you don't like please let me know and I can fix it
up quickly.
Thanks,
Scott K
