6:43 p.m.
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