Notes: idpy dev call, 21 July 2020
by hlflanagan＠sphericalcowgroup.com
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
