Attending: Heather, Ivan, Rainer, Martin, Jonas, Scott, Frederik Regrets: Benn, Roland, Leif 0. Agenda bash 1. särimner and Satosa (managing Satosa as a service) - how can SATOSA run behind a load balancer or with multiple gunicorn workers, as unsolicited-requests need to be shared between the processes - if there is a way to gracefully restart/reload SATOSA to load a new configuration Satosa needs state during the authentication flow; otherwise nothing is needed. These are very short-lived sessions. Satosa needs to know which requests are SP initiated as opposed to IdP initiated; these requests are unsolicited. When you get a response, you get an ID; if you have an unsolicited request, it needs to hold on to the ID long enough to match to an SP request to see if there is a match. If the SP won’t allow this, why have the policy enforced by Satosa (and therefore a load balancer)? Shouldn’t the SP just drop it? If Satosa gets an SP initiated request (stage 1), it needs to store that somewhere so when it gets to stage 2 (info from the IdP), it can drop requests that didn’t pass stage 1. This could be stored in a database or with the user. If we’re talking about front-channel flows, the info could be stored with the user; no state issue, as long as sticky sessions are required. If we’re talking back-channel communication, that’s another layer of complication where we need another mechanism to store the state (a database or shared memory). Alternatively, use client-side browser storage to hold an encrypted key; this would remove the requirement for sticky session (which would be a good thing - more scalable). Who is trying to do IdP initiated flows and support the back channel? No known use case. We should be mindful of spending resources on this unless and until we have a driving use case. Rotating short-lived keys: do these keys using a AES algorithm need to be rotated at all? One opinion is no; that crypto algorithm is not broken. Concern is if you have a busy Shib IdP, and you’re not rotating the key, it gives the attacker enough sampling that over the course of a few days, they have enough stats to go after that key. If you have a lot of clear text on the short data string, yes. But you’re assuming the attacker captures ALL the users’ sessions. If you’re using TLS (encrypted data channel) then this shouldn’t be a problem. 2. PR status Mostly working on the pySAML PR regarding time (see email to the list) Ivan requests that people prioritize which PRs are important to each individual, to help him with the overall prioritization. Please send that info to the list. - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) Encrypting responses: this is related to some other items re: how pySAML handles certain options. PySAML does not handle those options, only Satosa handles them and then passes them along to pySAML. That isn’t right; they should be handled by pySAML. The same thing should happen with the encrypted responses. Ivan wants to work on this soon. Scott notes that there is a fundamental issue here - the encrypted response from Satosa is not consumable by the Shibboleth SP because the key is named and the SP doesn’t recognize the name (pySAML is just making up a name for the key). - Satosa microservices - pySAML (https://github.com/IdentityPython/pysaml2) 445 - date/time issue. Has a new module that implements duration and date/time. All time related operations are done within this module. This is isolated from the rest of the code. All the validations and parsings that need to be done should also be handled this way. This will be a big diff; it will be hard to review, but will split into smaller commits to try and make it more manageable. Jonas will review. Issue 510 - when you have an external link in an XML doc, and you pass it to XMLsec1, it will try to resolve it, and bad things will happen. There is an option to turn this URI option off; have done that and merged this fix, but now need to look at the other calls to the XMLsec binary to see if they are doing something similar. Issue 508 - also related to 497, Ivan would like to work on this, and it will be handled in a similar fashion to date/time: will create a module that will control everything about XML handling. - pyFF (https://github.com/IdentityPython/pyFF) 3. OIDC libraries - pyOIDC - fedOIDC* Problem remains that there is no one on the call that could make the java libraries a priority; we don’t have the java developers available to do that. The code likely would not be developed in parallel unless we could find the developers for it. If we can find java developers, then the group is OK with taking the java libraries in along with the python library. 4. Governance update and CLAs (or not) Would really like to have a lawyer, though if we do, we’re going to go down the path of more paperwork than people expect for an open source project. 5. AOB