4:14 p.m.
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