Hi !
December 14th 17:00-19:00 CET I will hold a seminar:
"If you ever have wondered why a software package looks like it does now is your chance to get to know all about one package. In this seminar I will describe the underlying architecture of IdpyOIDC, a software implementation of all things OpenID Connect and OAuth2. The intended audience is both implementers and people the are using or plan to use IdpyOIDC in a project.”
The link to the Zoom room is https://sunet.zoom.us/j/63605279502
— Roland
Attendees:
Roland, Ivan, Matthew, Heathter
1 - Administrivia
a. Website update - need to mention all the idpy OIDC projects, djangosaml2; Heather to check GitHub to see what else is missing from the website
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Roland has updated the federation libraries to match the spec. Will be running an interop event in the next few weeks
Working on a seminar re: the design architecture for the OIDC projects, but that will require some updates to the code to match the architecture he originally designed. The project has strayed a bit from the original design (which is an expected evolution). Roland will announce this on the idpy slack channel. Expect at least two hours. There will be a slide deck and/or notebook that will also be published.
grantmanager has been updated as per feedback from Giuseppe
b. Satosa - https://github.com/IdentityPython/SATOSA
Matthew haas aa reference implementation of Satosa in AWS. Working on getting approvals from his employer to publish it. Will be doing Internet2 TechEx ACAMP sessions on the docker image and how to use it to get started. It's similar tot the Shibboleth reference implementation on AWS. This is intended to show a quick start to Satosa. Will want to add on proper validation testing (unsure how to do that now).
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Planning to make a release (see updated document on how to publish a release). Will also name it alpha or beta to see how that works.
One big MR (https://github.com/IdentityPython/pysaml2/pull/877 - reformatting code, removed older python code, fixes as part of flake). Once this is done, will push the new docs out to readthedocs.
• pyupgrade to fix "legacy Pythonisms"
• autoflake to remove unused imports (either left behind by pyupgrade, or otherwise unused)
• flynt, to fix non-f-string string formatting
• flynt -tc, to fix string concatenation too (which is more intrusive and could be unsafe, but tests should catch things)
More changes in the queue:
• https://github.com/IdentityPython/pysaml2/pull/878 - response name id instead of response assertion name id; similar to issue 866. What's proposed directly in this PR isn't ideal for a broader audience; choices need to be explicit and under the implementer's control
• https://github.com/IdentityPython/pysaml2/pull/866 - changing the default behavior and requiring signed responses by default; there is a suggestion to not allow unsigned responses at all, but that makes testing harder. There's also a lot of broken stuff out there, so being able to turn signing off selectively is aa good debugging tool.
• https://github.com/IdentityPython/pysaml2/issues/879 - OpenSSL library updates (not related to the recent bug). Ivan wants to remove dependency on this library.
Will be diving into some of the older PRs after this new release.
Thanks! Heather
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
