4:43 p.m.
Attending:
Johan, Heather, Ivan, Hannah Sebuliba, Scott, John, Christos
Regrets:
Giuseppe
Notes
1 - Status of architecture documentation
No update since the last call.
For architecture in general, Ivan will be adding some patches for the middleware idea. The
configuration will be part of the middleware; this will not be a breaking change. Also has
some additional ideas to wrap parts of the applications (e.g., what we do with the micro
services). This would allow easier to extend the micro services.
2 - Potential new project for idpy - status?
a. https://github.com/knaperek/djangosaml2
Notes from Giuseppe:
djangosaml2
Jozef Knaperek (the current repository owner) expressed a favorable opinion for the
migration to idpy. I lost him during the holidays but it's probably right that it was!
Watching djangosaml2's contributors we can see how many guys contributed in it and
also in pysaml2. I think that this migration would be quite natural for many aspects, one
of these is the opportunity to extend its community, abandoning the position of
"mantainance fork" moving into a more proper and authoritative space. For those
who do not know djangosaml2 this is the integration of pysaml2 in Django Framework, it
help us creating a SAML2 SP in the full respect of pysaml2 approach. I am sure you have
already given it a look. The latter commits have handled a SameSite cookie workaround,
similar to which already seen in SATOSA and we are getting ready for a major release
(v1.0.0) with a general code refactor (ClassView) and a better code coverage (>89%).
v1.0.0 would be a LTS release and probably we'll have a RC for some months before do
that. v1.0.0 would have also pysaml2 >=v6.1.0 as dependencies and we're facing
pysaml2's breaking changes regarding this. Finally, I'm only a repository admin
that are driving djangosaml2 best I can and, at last but not least, a real stakeholder,
because I largely use it in my production contexts.
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP,
JWTConnect-Python-CryptoJWT, etc)
Notes from Giuseppe:
I didn't still produced a debate in #oidc channel, but if I were did it I'd ask
about the default policy that oidcendpoint have, regarding the requested scope against the
supported or availables, for each RP. In that issue I tried to describe my (usually
coloured) experience: https://github.com/IdentityPython/oidcendpoint/issues/73
The goal of this debate would be the possibility to configure the default behaviour
(policy) in oidcsession, through oidcendpoint global configuration, that will let each
platform administrator decide how to handle the release of unavailable or unallowed
scopes.
That's a reference for this:
https://github.com/IdentityPython/JWTConnect-Python-OidcService/blob/51df9e…
Notes from Ivan:
There has been a bug in one of the underlying libraries for ECC crypto in the OIDC
endpoints. It is not handling exceptions well. It is fixed, but there is not a release
yet. When there is a release, need to force the use of the patch.
b. Satosa - https://github.com/IdentityPython/SATOSA
Ivan is reviewing current issues to come back up to speed.
Mostly working on middleware to add flexibility to what we do.
Ivan is considering the issue of multiple key descriptors - how can we define and
coordinate keys? Currently the configuration is messy.
• See also: https://github.com/IdentityPython/SATOSA/issues/334
Merge requests under consideration:
• https://github.com/IdentityPython/SATOSA/pull/332 - dynamic requested attributes. Will
be incorporated soon.
• https://github.com/IdentityPython/SATOSA/pull/231 - unsolicited front end work
Will just merge changes as long as they are not breaking changes. All breaking changes
will be held and done in one release.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Potential memory leak. Ivan has been using a function trace library to find this
(https://functiontrace.com/) It could not follow the forks or threads that were created,
but there is a new release of the software that should be able to do that now. eduTeams
has a test environment that has a test environment that Ivan will use to continue to track
this issue down.
Several pending merge requests:
• https://github.com/IdentityPython/pysaml2/pull/711 - request signing. Very simple,
should go through
• https://github.com/IdentityPython/pysaml2/pull/704 - Assumed name format for different
attribute elements. The spec dictates that, by default if no format is set, it should be
unspecified, which is not what we’re doing. This is a both a breaking change and a fix.
This PR also points to https://github.com/IdentityPython/pysaml2/issues/601.
• https://github.com/IdentityPython/pysaml2/pull/665 - how temp files work on Windows.
Named temp files don’t work correctly on Windows. We need to wrap this in our own
class/structure and detect when we’re using Windows and do things on our own on that
system. We can either fix this or not use these files at all (doing these operations in
memory), but the library that provides the bindings only has bindings for signing not
encryption.
• https://github.com/IdentityPython/pysaml2/pull/660 - allows multiple certificate files.
Ivan will be making some changes to the code.
•
https://github.com/IdentityPython/pysaml2/pull/645 and https://github.com/IdentityPython/pysaml2/pull/628 -
need to change the default algorithms and make them configurable. Will not support MD5 at
all. It is easy to display what we support but harder to do internally. These are still a
work in progress.
• See also: https://github.com/IdentityPython/pysaml2/issues/712 - the user is using
ECC keys for the signing, but internally we assume RSA keys
d. pyFF - https://github.com/IdentityPython/pyFF
4 - AOB
Next call: 15 September 2020
Thanks! Heather