2:03 p.m.
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