4:03 p.m.
Attendees
Roland, Scott, Giuseppe, Heather, Johan, Matthew, Hannah, Ivan, John P, Leif
Notes:
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP,
JWTConnect-Python-CryptoJWT, etc)
Roland and Giuseppe started looking at abstract storage - a way to persist information
that the OP/RP gather during their lifetime. Started a draft to describe this, and an
implementation using SQL Alchemy. This changes the CryptoJWT API slightly. There is an
abstract storage library now in GitHub, and Roland has a branch on CryptoJWT (abstorage)
that uses what Giuseppe has.
See PoC: https://github.com/peppelinux/pyAbstractStorage
Ivan notes we probably want to avoid being tied into SQL Alchemy, but the design should
allow for other possibilities (e.g., MongoDB)
Please review and submit issues or PRs.
b. Satosa - https://github.com/IdentityPython/SATOSA
Still working on the exception handling, designing a layered approach to how we handle
errors. Instead of a single function, will try to propagate exceptions to other layers so
they will handle them as they need.
Also doing work on the loggers and have a few things ready. Before he pushes, want to make
sure we have a compatible path for the new library and dependencies. This is based on
structlog.
Whenever the state of the proxy is saved in the cookie and when the user redirected to
another service, we need to clean up the state of the cookie. We’re not near any limits
wrt the cookie, but this will be a way to keep things clean.
One use case: stopping a SAML flow with Satosa, and then allow the user to go through an
entirely different SAML flow that still uses the same Satosa instance, then put the user
back into the original SAML flow. An example of this is a step-up flow. Ivan has some code
that does this. The consent microservice also does this. The routing mechanism, though,
needs to be rewritten. This will one of the bigger refactoring we need to look into.
https://github.com/IdentityPython/SATOSA/pull/322 - the flow that can start from the
discovery service; this has been deferred for a while - is it ready to roll? Not yet; will
review on next call
https://urlproxy.sunet.se/canit/urlproxy.php?_q=aHR0cHM6Ly9mdW5jdGlvbnRyYWN… -
allows you to get info from a running service. Ivan is trying to make this work with
Satosa; it was originally designed to run around an executable, not in a flow like ours.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Someone reported an issue where building rpms was not working. Given the age of these
systems, we’re not going to try and fix this. Even if we wanted to support this, it is
more properly an issue for the Python maintainers.
Another issue ( https://github.com/IdentityPython/pysaml2/issues/675) was about pylint
errors - most of the issues were a result of not all libraries being installed.
On the list:
• https://github.com/IdentityPython/pysaml2/pull/662 - want to merge 662 (cleanup on the
name of the id attribute used by xmlsec in order to encrypt/decrypt/sign XML documents,
specifically SAML).
• https://github.com/IdentityPython/pysaml2/pull/665 - Also want to merge a fix for the
tmp file creation. Python gives you a way to create tmp files, but this only works for
UNIX systems. This needs to be refactored in order to support Windows.
d. pyFF - https://github.com/IdentityPython/pyFF
2 - AOB
FastFed - could the structure be useful to us? Maybe - the work started with
a specific task to connect an OP with an SP. But this does not meet many of the needs of
Higher Ed, and many in the higher ed sector have voted against it. The vote did pass, but
they have asked for a representative of the group that voted against it to join and work
with them on the spec. They had asked early on if they could use the OIDC federation work,
and that would have covered many points but not the attribute mapping issues they also
had.
The proxy should do attribute mapping better as well; that’s on the list.