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
Attendees:
Giuseppe, Ivan, Matthew, Heather, Johan, Hannah, John
Regrets:
Scott
Notes:
1 - Status of architecture documentation
No update; focus is on finding a memory leak.
Will be expanding on the internal data representations, and how the microservices are applied to data representations, and how they get back to the external protocol.
2 - Potential new project for idpy
a. https://github.com/knaperek/djangosaml2
Giuseppe has invited Joseph, the maintainer, to these calls to see about bringing in djangosaml2 under the idpy umbrella.
As a reminder, here are the instructions for adding a project to idpy:
https://github.com/IdentityPython/IdentityPython.github.io/wiki/Adding-and-…
Heather will follow up with the Board in September re: the new project.
3 - GitHub review
Ivan is spending most of his time right now hunting down a memory leak. Other coding is delayed. See Satosa update.
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Status of pkce? OIDC endpoint has support for pkce (a better type of implicit flow). Ivan will be following up on that; sounds interesting.
https://github.com/IdentityPython/oidcendpoint/blob/master/src/oidcendpoint…
Question about whether this generates JWK? We do have scripts that can generate the keys:
https://github.com/IdentityPython/JWTConnect-Python-CryptoJWT/tree/develop/…
You can specify what the key will be used for via the ‘use’ parameter. We currently do not specify that, but might be useful to have. Then it will be easier to generate and use those keys.
b. Satosa - https://github.com/IdentityPython/SATOSA
When running Satosa, a host with 1GB of RAM, after about 3-4 days of processing requests, the memory usage has increased. It’s a slow leak in newer versions of Satosa. It may not even be Satosa itself, but one of the libraries (e.g., OpenSSL library, libxml). If you are restarting Satosa regularly, or don’t have a lot of traffic, this may not be a major impact to you.
Using https://docs.python.org/3/library/tracemalloc.html to help hunt down the source of the leak.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Name format work: https://github.com/IdentityPython/pysaml2/issues/601. PySAML2 assumes the name format value is a URI format. This is a bug on the consumption side. When we parse an attribute element and we don’t find a name format attribute, we should indicate that it is unspecified. When we produce an attribute element, then we have an object and we initialize it with the name format, the name of the attribute, and the value of the attribute. If we don’t specify the name format, then the default is a URI format. We may shift to indicating everything is unspecified unless specified as a URI format.
d. pyFF - https://github.com/IdentityPython/pyFF
4 - AOB
Ivan will be on vacation and miss the next call (August 18); we will cancel that call. Next call is 1 September 2020
Thanks! Heather
Attendees:
Ivan, Giuseppe, Scott, Heather, John
Regrets:
Roland, Matthew
1 - Status of architecture documentation
Ivan wrote up a page on middleware: https://github.com/IdentityPython/SATOSA/wiki/Middlewares
Will be adding more on the usage of of middleware, enabling and disabling them.
Question raised if ASGI is something we want to consider in place of or in addition to WSGI. ASGI is generally a good thing. If performance was critical, this might be of interest where we’re worried about reading/writing to disk, timing, and encryption. Mostly, we don’t need the asynchronicity so the cost in terms of refactoring the code is not worth it.
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Giuseppe and Roland have been working through new feature requests (e.g., a configuration validator) which might also be of interest for pySAML2. See https://github.com/IdentityPython/oidcendpoint/issues/70. Many ways to implement this, suggest including the documentation in the validator. This could be a schema. Ivan suggests looking at https://pydantic-docs.helpmanual.io/
b. Satosa - https://github.com/IdentityPython/SATOSA
Added the middleware documentation to the wiki space (see above).
Fixed the metadata generation for the virtual frontend.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
New release is out, which includes changes from Johan needed for the eIDAS proxy node. Mostly changes in the aggregate maps. Some fixes in the docs. New general config option for creating entity attributes that we don’t have specific configurations for. Allows us to set the friendly name attribute and values. See https://github.com/IdentityPython/pysaml2/commit/e5d0b4f0760144430d885165d4…
NameID format config has been changed, and how we handle the NameID format policy. This was a breaking change. See https://github.com/IdentityPython/pysaml2/commit/0c1873da1f280d4921b9c9b3da…
Working on changing the default algorithms. We do need to decide what we want the new defaults to be (currently SHA1). Changing the defaults will be considered a breaking change. Still need to work through how this will be configured. SHA1 is hardcoded in some places. We need better defaults for signing and digesting pieces of XML documents. Given what we do (we are not in a high performance environment) the slight performance hit of SHA512 over SHA256 may not be significant. When issuing responses with poor vendor implementations of SPs, we have to consider whether they can handle the more complex algorithms. We will go with SHA512 as our choice, but need to be clear on documenting how to change the default and consider how to set this as a per-SP choice.
We use a cert to check the types, and whether some things are verified. This is not ideal; certs are stripped out when python code is compiled. Will replace the certs with exception raises, making the type of exception reasonable.
d. pyFF - https://github.com/IdentityPython/pyFF
3 - AOB
Backend initiated responses
Scott has a modification to the SAML front end to support unsolicited flows, so that you can have a URL and specify all the details you want for the flow. This has been useful in COmanage when, after a registration flow, there is enough information to send the user to a specific SP based on their enrollment. If anyone else needs this kind thing, please contact Scott.
Typehints - Should we be using these? Yes, where they make sense. If we can have actually schemas that can verify input/output, and within the system we can then rely on the data that has been verified, that would be good. Typehints should be set where the API is defined.
Should we consider incorporating Django SAML into idpy? Giuseppe will reach out to the Django SAML team and see if they are interest, and then send a message to the idpy-discuss list for feedback.
Thanks! Heather
Attendees:
Giuseppe, Heather, Ivan, John P, Hannah, Christos
Regrets:
Scott
Note:
0 - Agenda bash
1 - Status of architecture documentation
All this started around the idea of middleware; these will be a configurable set of things. Ivan continues to develop his ideas on this, has not yet started writing these down.
Will also be creating an identifier for any request that comes in; that will allow us to mark requests as unsolicited as needed, and change how we process it.
Microservices look like middlewares, just not at the network level.
Alternatively, may start developing something called interceptors instead of middlewares; Ivan still investigating the possibilities.
Look to the wiki space in Satosa GitHub for upcoming documentation. May also be creating diagrams (using https://plantuml.com/) that will explain at least part of the flow.
We still need better basic documentation to get people started; problem is Satosa is so complicated, it’s hard to put together good documentation.
In terms of diagrams, Ivan is also looking at:
- https://www.websequencediagrams.com/
- https://plantuml.com/
- https://app.diagrams.net/
- http://blockdiag.com/en/blockdiag/index.html
- https://www.lucidchart.com/
- https://www.gliffy.com/
- https://creately.com/
- https://miro.com/
One question about using signals to help automate the documentation, but that won’t work for Satosa, which doesn’t use a framework that would support that.
Note that Rainer created some graph diagrams for Satosa as well about a year ago ( https://github.com/IdentityPython/SATOSA/pull/263)
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
b. Satosa - https://github.com/IdentityPython/SATOSAhttps://github.com/IdentityPython/SATOSA/pull/322
People are bookmarking the discovery service as their initial landing page to a service, but that leaves the SAML backend confused as to which front end the discovery service belongs to in that scenario. Scott, Ivan, and Matthew have talked about whether the backend should have its own discovery flow. We would need to define a list of strategies on where to get the target service, and the backend would need to make that part of the context so the front end would know what to pick up and send back to the service. This is doable, but not trivial to code.
Could throw an error that lets the user know they need to start at whatever service they want to go to. Not sure this would work either, because the user may well not know the URL to the service URL. Alternatively, have a generic landing page that contains links to all the services and let them pick from there. This page would be created by the deployer, and not automatically generated by Satosa. Can be implemented in the same way that the unhandled exceptions will be handled.
Ivan will need to finish writing up and then implementing middleware, and then we can work on this issue.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Ivan has been looking at refactoring name_id_format (https://github.com/IdentityPython/pysaml2/issues/669)
Ivan has a patch, but it is a breaking change. New option is called name_id_policy_format. The policy format specifics what happens with an authN request is created, and the name_id_format options is only used to define what’s in the metadata. Name_id_format can have multiple values (the order of the values matter) while the name_id_policy_format only takes a single value which, if not specified, will not be set. The “none” string is now gone.
Ivan plans to do a non-breaking release first with some other changes, and then will introduce this breaking change.
Also looking at https://github.com/IdentityPython/pysaml2/pull/628 that will allow us to disable weak algorithms. This is a good initial step, but it’s not really enough. pySAML2 defines different algorithms that it knows how to work with, as does xmlsec. We currently ask xmlsec to give us that list, getting a different set depending on xmlsec version, and then we compare it to what pySAML2 knows how to handle. If we follow this pattern, we will need to update pySAML2 with the list of what it can handle. Alternatively, we can store a restricted last that will focus on what to disable, rather than what to support. The trick is that we need the proper namespace names out of xmlsec rather than the short names we get now. We also need to define proper defaults (right now, the default is SHA1). We should disallow md5.
Hopes to have something by the end of the week that will get us moving in the right direction by configuring the choice of algorithms.
d. pyFF - https://github.com/IdentityPython/pyFF
3 - AOB
Thanks! Heather
Hola a todos!
We’re canceling the call for tomorrow, Tuesday 9 June. Ivan is working on getting out new releases for Satosa and pySAML2. Keep an eye on the list and the slack channel for updates.
See you in two weeks!
Thanks! Heather
