Hello all,
(So much cross-posting. I can’t really even be sorry about doing it; the conversations are happening EVERYWHERE!)
The Federation & Browsers workshop this week was quite the experience!
tl;dr - a new W3C community group is forming to focus specifically on federated identity on the web. I am working on the charter with a handful of others, and hope to have our first call within the next 3-4 weeks.
The first day of the workshop was primarily presentations from browser vendors (Google, Microsoft, and Mozilla, with some short comments by Apple) and large IdPs (Google, Microsoft, Facebook). People were able to submit questions and vote on them to direct where we took day 2.
Day 2 was all about discussion, kicking of with a discussion on whether we all agreed to these two statements:
• Non-transparent, uncontrollable tracking of users across the web needs to be addressed and prevented.
• Federated login and tracking tools use the same primitives and are indistinguishable from non-transparent, uncontrollable tracking from the browser’s perspective; browser’s proposed mitigations for tracking will impact federated identity.
(Result: General agreement, but with significant uncertainty about the specifics.)
We wrapped up with a discussion about how to keep the conversation moving, and the group agreed to the formation of a W3C community group specifically focused on federated identity on the web. If and when a broader identity community group is formed (which would cover additional topics such as Decentralized Identifiers), then the federated identity CG would be considered a sub-group of the more general one.
I’m in the process of converting the notes to markdown format; their final location will be here:
https://github.com/WICG/WebID/tree/main/meetings/2021
You can already find some of the slides from presenters in that repository.
If you want an early look at the notes, they were taken in Google docs:
Day one: https://docs.google.com/document/d/16wj6UnlaePCE0sdVfkVSwoBMHuFphLuv2sptxdQ…
Day two: https://docs.google.com/document/d/1nZt-bU-9FeoaavSuB6KPC7d3vyKuOhnA5QAd8kT…
Thanks! Heather
Attendees
Johan, Heather, Giuseppe, Scott, Roland, Ivan, Hannah, John P, Peter Gietz
0 - Agenda bash
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
There are a number of packages in the OIDC space. Will be merging some of these to make for easier maintenance; nothing is being removed, just rearranged. Example: moved OIDC endpoint into OIDC OP.
This happened at the same time when we rewrote persistence storage, the session handling tools, and cookie handling.
Outcome: major rewrite from what we had before we started the work.
There are 3 issues open and 2 PRs that need to be dealt with. Goal is to sort out the PRs and issues and then release 2.0 later this week.
As always, there is an ongoing need for documentation.
---
Detailed merger breakdown:
CryptoJWT - OidcMsg -+- oidcendpoint - oidc-op
|
+- oidcservice - OidcRP
now we have
CryptoJWT - OidcMsg -+- oidc-op
|
+— OidcRP
We accomplished this by including oidcendpoint into oidc-op and oidcservice into OidcRP.
The inclusion was made in such a way the all classes and functions defined in oidcendpoint would appear under the same name in oidc-op.
This meant that users of oidcendpoint would in the future have to change
from oidcendpoint import XYZ
to
from oidcop import XYZ and everything would just work. Likewise for oidcservice and OidcRP.
Beside doing this change we also rewrote:
- session management
- persistent storage
- cookie handling
Regarding persistent storage and cookie handling our goal was that the oidcop should not deal directly with these tasks.
Oidcop should provide a frontend with access to the information that should be stored in/retrieved from a persistent storage but not handle the storage per se.
Likewise oidcop should provide the information that should be in the cookie payload (the cookie value) but not construct and release cookies.
---
Suggest updating the readme of the retired packages and then archive those packages so they are read-only.
Giuseppe has offered some updates on the federation draft. Looking for more organizations willing to pilot the spec. There are some concerns re: the security considerations section. There is a potential for a DoS via one of the APIs. That needs to be included in the security considerations section with some kind of statement that standard mitigations for DoS applies.
Release-drafter notes: https://github.com/IdentityPython/oidc-op/releases/tag/untagged-fad801bc6e3…
b. Satosa - https://github.com/IdentityPython/SATOSA
Planned work on Satosa is around the cookies. When we get a request, we hardcode which part of the request will be kept. Giuseppe is helping build the list of what will be kept.
Peter Gietz has developed several microservices for Satosa:
----
Production ready implementation of:
• Authentication against an LDAP server
• SCIM attribute store to fetch attributes via SCIM API (instead of LDAP)
• Authoritzation module for blocking services if necessary group memberships or attributes are missing in the identity (for service providers that do not evaluate attributes themselves)
• Backend chooser with Django UI for letting the user choose between any existing SATOSA backend
• Integration of MFA via PrivacyIDEA
Prototype implementations of:
• OAuth2 frontend supporting different OAuth2 flows for clients
• Authentication via TLS client certificate
• Authentication via Kerberos
These all are more or less capsuled as Micro Service, so although we would be happy to contribute the production ready stuff, we would have no problem to keep it as separate Open Source publications.
This will not be possible in a next project, where we need to do amendments in the core product. Basically it is about implementing an optional feature (Key ID in the JWKS response). Here we would have a big interest if this can be taken over into the SATOSA distribution, so we do not need to create a fork and maintain that. Our motivation: we encountered an application that expects such and throws errors, if KID is not present. David or I will write a separate email with more technical details on this.
Code is currently hosted here: gitlab.daasi.de
---
Question as to where to host these, either under Satosa or under a separate repository. If hosted under Satosa, then they will need to be managed in parallel with the other changes in Satosa. If hosted separately, then the maintainer (Peter) has more flexibility about how and when code is updated to match. A third option involves having a separate repo for microservices which will allow more flexibility for deployers to choose what to install; this will be the eventual direction for all microservices.
For now, we will add pointers to the gitlab code.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
New releases for pySAML2 (v 6.5.2 and v 7.0)
• https://github.com/IdentityPython/pysaml2/releases/tag/v6.5.2 - added support for the Shib metadata scopes; various bug fixes; see release notes
• https://github.com/IdentityPython/pysaml2/releases/tag/v7.0.0 - breaking change that changes the default encryption methods. Default algorithm is now rsa-oaep-mgf1p
• next: looking at the old PRs for certificates (how we load them, how we use them, etc)
d. pyFF - https://github.com/IdentityPython/pyFF
Thanks! Heather
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
