Hola a todos!
With many people in Europe enjoying holidays the first part of this week, we’re going to go ahead and cancel the idpy developers call tomorrow, May 4. That said, you are welcome to join the informal call I’m having at 16:00 UTC on the changes happening in browsers that impact SSO and federation. I’ve mentioned this on the Slack channel; if you would like to be added to the invite (and haven’t told me that already) drop me a note and I’ll add you.
It is not going to be recorded - did I mention it’s very informal? - but there are slides I’m happy to share.
Thanks! Heather
Attendees:
Johan, Giuseppe, Ivan, Heather, John P, Hannah
Regrets:
Scott, Roland
Notes
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Ivan is considering restructuring how OIDC is used in Satosa, breaking them up from the front end into microservices. Ivan will make a prototype to test out the idea. This is not high on the priority list.
Johan is looking at the next iteration of the OAuth spec (https://oauth.xyz/) Will talk in the future about how that might impact our project.
b. Satosa - https://github.com/IdentityPython/SATOSA
Preparing a bigger release, including many local commits (mostly changes merged into eduTEAMS). Also
• https://github.com/IdentityPython/SATOSA/pull/363 - cookie properties
• https://github.com/IdentityPython/SATOSA/pull/365 - http headers
• https://github.com/IdentityPython/SATOSA/pull/366 - IdP hinting
Expecting to get this out this week.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Preparing a release for pySAML2. Has merged:
• https://github.com/IdentityPython/pysaml2/pull/778
• also some local commits
Expecting to get this out this week.
After release, will focus on encryption and signing.
d. pyFF - https://github.com/IdentityPython/pyFF
No update
e. Other info
Current priority list for Ivan:
• Refactoring core of pySAML2
• Handling of friendly names
• Changing the configuration to allow custom encryption, decryption, and signing algorithms
• Will add a priority label to current open issues
Heather to add djangosaml2 to the list of projects we check in on during these calls
2 - Discussion
a. Browser interactions and federated identity
Things that are absolutely going to break:
• Global logout in SAML, OIDC front-channel logout, token refresh via iFrame in OIDC
• There are currently no mitigations available; figuring those out is under discussion.
Useful reading material:
• https://github.com/WICG/WebID/blob/main/README.md
• https://github.com/WICG/WebID/blob/main/cookies.md
• https://github.com/IDBrowserUseCases/docs/issues
There will be a workshop, held under the auspices of the W3C's WICG on May 25 & 26 from 10am-1pm US Pacific. This will be free, but you must join the WICG (also free) so we have the necessary IPR coverage. https://www.w3.org/community/wicg/
Thanks! Heather
Attendees:
Johan, Scott, Hannah, Roland, Heather, Ivan, John P
Regrets:
Giuseppe
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
New draft published for the federation draft (see blog post: https://openid.net/2021/04/03/openid-connect-federation-specification-resul…) Next step will be to bring it up at the OIDF board meeting to see if anyone is opposed to making this a standard (meeting on Thursday).
Rewrite of the JWGConnect stack is continuing. Session management is a big component of the work in progress.
b. Satosa - https://github.com/IdentityPython/SATOSA
Working on IdP hinting, which backend to use, and reworking the base URL to allow it to have a path. Christos is asking for a way to group front ends and back ends such that they will only interact with each other, grouping them such that they can only talk to specific IdPs or they can only talk through a specific backend. This might also be called a multi-tenant Satosa instance.
• how would the microservices need to change so they react appropriately to the different groupings? focus has been on the connection points at the front and back end. A microservice is a backend module. On the config, we could say there is a path to that class to load it, and it has a unique name. We could have the same python code invoked by multiple configurations. Given the name is different and the config is different, if we had groups we could use the microservice in the processing with this configuration, and the other group could reuse the code with a different configuration.
• The microservice can have resource consuming qualities, so might not want to have microservices duplicated, because it might consume the same resources.
• We'll have to change the configurations to support this multi-tenant model
• would like to preserve functionality where microservices receive query string parameters or parts of URL; they'll need to be able to inspect the URL that was invoked at the start of the flow.
Expect a new release soon for this and for pySAML2. CI is being reworked; will be experimenting with GitHub actions.
Question re: Single logout (SLO) for Satosa - with a proxy, there is no actual state, which makes SLO difficult. The service knows that the user came from the proxy, and it will tell the proxy to logout the user. The proxy will get the logout request, it will probably have the nameid, but there is no mapping to which was the initial home IdP of the user, and what is the actual identifier for the user.
• Be aware that if anyone tries to solve this using third-party cookies, it will not work with Safari users, probably won't work with Firefox, and soon won't work with Google users (general deprecation of third-party cookies). See https://github.com/WICG/WebID for a write up of the problems.
• To do this, there will have to be a place to store the state, probably on the server side. We could also generate an identifier that only Satosa knows about, store it somewhere (by default in memory, but could be a database). We could use these to map back to the IdP and invoke an SLO request. This only addresses the ability to start the SLO process, but there are other issues to consider beyond creating the request. There are different types of logouts (front channel, back channel) that would need to be supported. Front channel would require each service be contacted to logout, which won't work.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Will be adding a new filter on the metadata side to handle scopes. Will also be merging some PRs from Giuseppe. Expect a new release soon.
d. pyFF - https://github.com/IdentityPython/pyFF
Folks,
In an effort to deal with an extreme case of release-phobia I just pulled the
plug and created the following two tags:
- 1.2.0 with most of the outstanding PRs, bugfixes etc
- 2.0.0 that starts from 1.2.0 and drops all frontend code (html etc)
Using some gunicorn trickery 2.0.0 still has a pyffd that runs the wsgi app with
a config which closely matches the 1.x behavior: other than the fact that there
is no frontend in 2.x, as an mdq service it behaves much like 1.x does.
The 1.2.0 will for now remain an (unreleased) tag which can be used by those who
want all the fixes in "pre-2.0" but are not ready start testing 2.x yet.
The 2.0.0 release has been deployed to pypi and the github.com/SUNET/docker-pyff
docker image has been update to support building both 1.x and 2.x release trains.
Treat the 2.0.0 release as a starting point for the 2.x release train - there will
most certainly be bugs etc but please start testing and keep those bug-reports
coming!
Cheers Leif
Attendees
Heather, Ivan, JohnP, Hannah Sebuliba, Johan
Regrets:
Scott, Roland
0 - Agenda bash
New Incubator - GEANT has a program where they sponsor a team to do a project that will serve as the basis to do something bigger. Niels suggested that we use the incubator program to set up a matrix of idpy projects to determine if the communication is working properly between all the different services. Ivan will send the suggestion about this to the list. The trick will be that it's often the configuration, not the software itself, that causes the problems. The matrix would need to be more about common configurations rather than just a default deployment, but it's an open question as to how what configurations we would choose. Ivan will follow up with initial meetings to see if this can be applied to us, but this won't be a high priority and someone else may want to eventually take point.
What if we started limiting support to specific profiles of configuration? The challenge with that is we don't really know all the ways that idpy apps and libraries are used. If we do go down this path, we'll need to document carefully because it will impact what we test for, what issues are valid, etc.
1 - Governance policy updates
Board has approved the updated policies, with a few minor changes (specifying ideal test coverage at 80%, requesting that the common incident handling policy is followed)
https://github.com/IdentityPython/Governance
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
No update
b. Satosa - https://github.com/IdentityPython/SATOSA
New release expected soon. We have a new contributor to the code base.
• https://github.com/IdentityPython/SATOSA/pull/354 - will be a breaking change for OIDC plugins; see documentation
• will be some other updates to various microservices
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Has just about finished the code that will let us update to new algorithms. Ivan will merge the PR (https://github.com/IdentityPython/pysaml2/pull/778) soon, set up some new GitHub actions (first time we'll be using these) and cut a new release.
Several people are working in the same part of the code, so we need to come to some conclusion on the crypto pieces. Ivan will be reviewing the different PRs and figuring out what and how to merge the ideas if not the exact code.
• https://github.com/IdentityPython/pysaml2/pull/781
• https://github.com/IdentityPython/pysaml2/pull/660
• https://github.com/IdentityPython/pysaml2/pull/787
Test Suite under development by Giuseppe: https://github.com/peppelinux/spid-sp-test. This could serve as a way to start doing integration tests. The tests make certain assumptions, which feeds the conversation about having specific support profiles (see Agenda Bash - New Incubator discussion).
Next up for pySAML2:
1. More work around signing and encryption to add lists of allowed/disallowed algorithms
2. Creating a python-based signing/encryption library (replacing xmlsec1)
3. Changing the base of pySAML2 using a proper parser and possibly using types (idea introduced by Davide Brunato)
d. pyFF - https://github.com/IdentityPython/pyFF
No update
Thanks! Heather
Attendees:
Ivan, Giuseppe, Heather, Hannah Sebuliba, John P, Roland
Regrets:
Scott
0 - Agenda bash
1 - Governance policy updates
• Joseph has transferred the djangosaml2 to the GitHub repository page
• idpy Board meeting next Thursday
2 - GitHub review
b. Satosa - https://github.com/IdentityPython/SATOSA
Merged a few things, but nothing major. We have a new person contributing to the code based, contributing new microservices and working with the OIDC backend.
• https://github.com/IdentityPython/SATOSA/pull/355 - feat: add support for the Scoping element and RequesterID in SAML2 backend
Question re: does SATOSA have support for SLO on the roadmap? Not right now, though Ivan recognizes we need to look at this. See also https://github.com/IdentityPython/SATOSA/issues/211. There are different types and methods to initiate logout, but it all comes down to a best-effort activity for the user.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Ivan has been looking at the PRs for both pySAML2 and Satosa and have merged some.
• https://github.com/IdentityPython/pysaml2/pull/757 - Handle all types of ACS endpoint specifications
• https://github.com/IdentityPython/pysaml2/pull/779 - Raise SAMLError on failure to parse a metadata file
• https://github.com/IdentityPython/pysaml2/pull/763 - Invalid Destination URL Exception Handling
• https://github.com/IdentityPython/pysaml2/pull/766 - InvalidAssertion Exception
• https://github.com/IdentityPython/pysaml2/pull/772 - Response with unvalued AudienceRestriction (Condition) Handling
• https://github.com/IdentityPython/pysaml2/pull/762 - Minor bug fix to metadata function in example IdP
Changes still under discussion:
• https://github.com/IdentityPython/pysaml2/pull/778 - [Strengthen Encryption] PySAML2 Encrypted Assertions now works with Shibboleth SP 3 - note that we will not be using RSA, but instead using RSA OAEP as generally recommended. Switching to RSA OAEP is a breaking change.
The main thing we need to work on more are the encryption pieces. More work needs to be done around signing, and how we configure metadata and internal processing about which algorithms we accept. This is close to being wrapped up, and then Ivan will focus on how to encrypt the payloads. Right now we depend on xmlsec1, writing files, etc. Given our recent security issues were a result of how xmlsec1 behaves, this whole set of functionality must change. We have all the pieces we need to do this ourselves, without relying on a library like xmlsec1. We can focus purely on something that meets the need and requirements of SAML.
eIDAS requires specific algorithms be supported, and those algorithms are not supported by xmlsec1. This is another issue for us. This will be a new security backend for pySAML2, and xmlsec1 will be kept as an option.
What about pyXMLsecurity (https://github.com/IdentityPython/pyXMLSecurity)? This is a side project. It was initially planned to be used by pySAML2 but it was never extended to include all the operations expected. It support signing and verification, but there is no encryption/decryption support, and even the signing needs more work. The code is messy. Some of Ivan's new ideas, though, will be taken from here (e.g., low level processes). We don't know if this code is being used by anyone in production.
d. pyFF - https://github.com/IdentityPython/pyFF
No update
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Roland is waiting for Nikos to sign off on the OIDC endpoint. When Nikos signs off, the project will start using that new code and Roland will need to update the documentation.
The OIDF has raised the fee for doing certification. They continue to discuss whether open source implementations should be able to go through certification, the challenge being how to define "open source". OIDF is willing to waive the fee for Identity Python. Roland will not try to certify for FAPI (Finance) unless we hear of a financial institution that uses our code that would require it.
The OIDC Federation spec is an implementer's draft right now. Roland is working with Mike Jones to edit some pieces, but it is largely stable. Hoping to get the vote kicked off to bring it up to a standard level soon (next month or so).
3 - AOB
Reminder: Daylight Saving Time clock skew about to start. Our next call will be March 23 @ 13:00 UTC.
Thanks! Heather
