4 p.m.
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