Hello all!
Given Ivan’s availability and the massive scheduling headache that is next week, I’m canceling Tuesday’s call. Our next call (unless something unexpected happens) is on 15 November 2022.
See you all on Slack!
Sent from my iPad
Attendees:
Roland, Johan, Ivan, Heather, Scott, Matthew, Giuseppe
Notes:
0 - Agenda bash
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
OIDC Federation version 23 has been updated and are now out for an unofficial final review. Need an editorial review as much as a technical review. Roland has updated his implementation to be compliant with this new version, in particular compliance with CIBA which required entities to be allowed to be more than one thing at a time. Expect to finish in 2-3 weeks.
Ivan is working on https://github.com/IdentityPython/idpy-oidc/pull/32. This adds support to revoke/invalidate tokens. Seems to work well in eduTEAMS.
Ivan is also looking at how to manage the audience for the policies and how that interacts with the resource indicators.
When will eduTEAMS front end become public? No date. No idea when this will be resolved.
b. Satosa - https://github.com/IdentityPython/SATOSA
Many changes; see discussion on mailing list re: supporting multiple ACS endpoints. See https://github.com/IdentityPython/SATOSA/pull/409. This will be configurable on the backend. Note that given the divergence of IdPs out there, will need to be able to configure this on as granular a level as practical.
We have talked about turning Satosa into a FastAPI service. Maybe when we make that change, we can also change/specify what runs when certain endpoints are involved.
There is also an MR about allowing Satosa to be configured under a specified path. The MR allows for the base path to be changed. https://github.com/IdentityPython/SATOSA/pull/405
Plans to make the error messages for cookies and context state available (discussed at TNC).
Would be helpful if others run flake8 on the Satosa code and fix bugs as they are found.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Ivan has converted pysaml2 to use poetry and has also reformatted the code.
See https://github.com/IdentityPython/pysaml2/blob/master/pyproject.toml, https://github.com/IdentityPython/pysaml2/blob/master/tox.ini
Ivan is going to release a 7.3.0-alpha version with the changes up to now, and then plans to
• get the CI working
• rework the docs - switch to mkdocs and update the content
• go back to the actual code (a few things there happening in parallel to the above)
Other development open for contribution:
• https://github.com/IdentityPython/pysaml2/issues/869#issuecomment-1256707533
d. Any other project (pyFF, djangosaml2, etc)
At the last idpy meeting, had a new djangosaml2 release. Nothing changed since then. Giuseppe has tagged a new version, but the pipelines don't work yet.
2 - Documentation
Note that all docs will (eventually) be switched to using mkdocs. When Roland is done with his work on idpy OIDC will work on converting documentation to mkdocs and using poetry.
See:
• a new README file: https://github.com/IdentityPython/pysaml2/#readme
• a DEVELOPER guide: https://github.com/IdentityPython/pysaml2/blob/master/DEVELOPERS.md
• a CONTRIBUTING guide: https://github.com/IdentityPython/pysaml2/blob/master/CONTRIBUTING.md
• a SECURITY guide: https://github.com/IdentityPython/pysaml2/blob/master/SECURITY.md
(a few things remaining as TODO) GitHub suggests that we additionally favor some Code of conduct document, but will skip this for now..
• https://github.com/IdentityPython/pysaml2/community
Still needs to work on the release documentation for pysaml2.
Thanks! Heather
Hi all,
in my setup, SATOSA may listen on multiple interfaces/ports/vhosts, and
not all are accessible to all users. Therefore when sending the
authentication response, the IdPs must redirect the users to the
'correct' AssertionConsumerServiceURL. The problem is that the SAML2
backend always selects the first ACS address in the request
(src/satosa/backends/saml2.py:289).
I'd like to select the ACS URL based on the host name of the request
(context["http_headers"]["HTTP_HOST"] specifically). What do you think
about it? Would you consider such a pull request?
I'm still not entirely sure what to do if there's no match. I guess
Shibboleth SP used to specify the ACS URL in the AuthnRequest using
information from HTTP_HOST(?), since I remember seeing error messages on
IdPs when no AssertionConsumerServiceURLs in the metadata matched the
request. Even if I remember right, this might not be the best approach,
because I could think that it'd be more user friendly if SATOSA could
signal the error instead of the IdP, but this might be use case
dependent.
Thanks,
Kristof
Hi,
What is exactly the relationship between the attribute name format and
the mapping within attributemaps?
I couldn't fully understand that part of the code, but empirically it
seems that only the 'last' mapping file is considered, so it's not
possible to have multiple files for the same attrname-format, only one
mapping per name format is allowed. If this is correct, then adfs_v1x.py
and adfs_v20.py being separate files is pretty misleading.
Also, the satosa tree contains a subset (I didn't verify, whether it is
a true subset or not) of the pysaml's default attributemap dir, what is
the purpose of that directory?
Thank you,
Kristof
Hi!
In my calendar there is an IdPy meeting today.
Heather said at the last meeting the she would not be able to make the one today, her being at a meeting in Amsterdam.
Unfortunately I will also be unable to make the meeting today.
— Roland
Attendees:
Roland, Heather, Johan, Scott, Matthew
Regrets:
Ivan, Giuseppe
OIDC Libraries
• session management code: session was defined as one users from one client having one authentication. Based on that and user consent we create a grant. eduTEAMS wanted client authentication with no user involved, so not an OIDC flow but an OAuth flow. They did this by using the client info twice, so Roland has changed session management to grant management, conducting sessions so there can be more clients, no users. Now needs to update the documentation; that's in progress (it's a mess).
• Getting closer to the final OIDC Federation specification. Authors are now meeting weekly to clean up all remaining issues. Roland is now working on implementing the latest version.
Single Logout
• Hannah still working on this. (see notes from last call)
Documentation
• Are poetry and markdown going to be the standard tools/formats for all idpy?
• note that we may be able to use pandoc to convert documentation where necessary
• Matthew is working on the function documentation. It's not complete, but will submit a PR with what he has
Thanks! Heather
Hi all,
As far as I understand, the 'sub' is the standard claim to release a
user identifier value when you use OpenID Connect frontend. But even
though the subject_id is properly set in the internal request, I can not
get the frontend to not change this value when it creates the id_token.
Is there a way to do this?
Or how do others release the user's identifier using OIDC? I can do it
using 'email' or a custom claim, but none of this seems to be The Right
Way.
However, I'm inclined to think that using 'sub' for the user identifier
is overly complex, because I want to be able to populate the subject_id
from a SAML2 NameID (on the backend side), which I can only do with a
response microservice, but I'm not confident that changing the
'subject_id' in a microservice is a safe and supported operation.
Thanks for any insight,
Kristof
Hi!
Having refactored the Session/Grant management I though I would just add some documentation
Famous last words…
We really, really need to rework the documentation.
This isn’t the first time that someone has said this.
Will probably not be the lats time either….
But let’s start small.
Could we at least agree on a layout, a set of chapters and in what order.
Maybe we could begin with deciding on who we are writing for.
Surely we will have readers that comes to us with different backgrounds/needs :
- An architect, who wants a birds eyes view over what the system can or can’t do
- A service provider, who wants a set of steps that will get a server running.
- An apps implementer who wants to know how to interface with the client API and use Google/Github/.. as the OP.
- A developer that wants to add another endpoint/service to the system.
There are probably more.
If we could agree on who we write for we could perhaps start there.
Maybe we should have a set of entry points depending on who you (the reader) are.
Something like the list above.
If I where connected to/employed by a big organisation I could imaging finding persons that fits the
profiles above and ask them what they want to know (the depth of knowledge they want) but I ain’t so
that’s not going to happen.
— Roland
Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826)
