[Idpy-discuss] Notes: idpy developers call, 11 September 2023

Idpy meeting 12 September 2023 Attendees: Giuseppe, Ivan, Johan, Matthew, Hannah, Shayna 0 - Agenda bash 1 - Project review a. General b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc, JWTConnect-Python-CryptoJWT, etc) - Review of Matthew E's pull request <https://github.com/IdentityPython/pyop/pull/52> on pyop and continuation of discussion that was started in Slack. - Summary : pyop (somewhat deprecated) is not compatible with PyMongo version 4+. Yet SATOSA depends on pyop for the OIDC front end. Pull request is a one line pin to the old version of PyMongo. - If the new front end is the way of the future, there should be some documentation that indicates that pyop should not be chosen for new deployments of OIDC. - Ivan could not find an example of a client connecting to the frontend; he should probably provide some examples of static and dynamic client registration. - Ivan says pyop is not deprecated but is also not properly maintained. Most of the effort is being put into idpy-oidc. However, pyop can still work with restrictions on dependencies. At some point pyop will be archived and everything will be switched to idpy-oidc. When this happens, they will not remove the existing packages/frontends that are available on SATOSA. Instead, deployers can choose to use either the old or new frontends/backends. So pyop is not replaced; the deployer chooses which ones to use. Pyop code base will no longer be supported by the team, but developers can make their own forks and make changes as they wish. Deployers will be pushed toward idpy-oidc. however, since this is where the focus will be. This would appear to make it so there is not a breaking release; however there will be one just due to the special syntax required to declare the dependencies you want. For instance you usually say: pip install satosa but then you will have to say something like: pip install satosa[idpy_oidc_backend] or pip install satosa[idpy_oidc_backend,saml2_frontend] etc. This is already done for the new backend - example in https://github.com/IdentityPython/SATOSA/blob/628ee94/setup.py#L34 line 34. If you specify idpy_oidc_backend then this pulls in at least version 2.1.0 of idpyoidc. There will be similar things for saml, etc. and it is already available for choosing mongo or redis: "pyop_mongo": ["pyop[mongo]"], "pyop_redis": ["pyop[redis]"] - This does have implications on the container/packaging side. The goal is to be more inclusive, but people can always create their own containers. - This document talks about other repos relevant to SATOSA - https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#external… One is satosa-oidcop. - Roland has requested to change how work is done in the idpy-oidc repo. Previously there were both main and develop branches, and all work was done locally against the develop branch. Eventually the develop branch would be merged back to the main branch and there would be a new release. Roland proposes working on the main branch directly. Releases are tagged as necessary. - Christos and Roland are going to make a release of the OIDC frontend that is used by eduTeams, probably this week. - Note: satosa-oidcop is working with MongoDB/pyMongo; the one used by GEANT eduTeams uses postgres. Doing this with something like Alembic might be better in the future. Some of the reason for using Mongo was based on that Roland initially coded using the filesystem for the storage layer, not a relational approach. Using a relational database requires rebuilding all the relationships, do cleanup, etc. Giuseppe used the load() and dump() abstract interface to the internal session storage engine. You can see practical examples of when these methods are used in satosa-oidcop. c. Satosa - https://github.com/IdentityPython/SATOSA - Roland's PR for removing saml dependencies: https://github.com/IdentityPython/SATOSA/pull/442 - Need to thoroughly review and make sure nothing else breaks. Also includes replacing some cryptographic operations with cryptography and cryptojwt libraries. - Ivan is preparing a new release - Looking at these PRs https://github.com/IdentityPython/SATOSA/pull/435 - typing https://github.com/IdentityPython/SATOSA/pull/438 - saml modules metadata store https://github.com/IdentityPython/SATOSA/pull/431 - SLO - Should the state storage be part of a specific module like saml backend, or part of core so that any module can use it? - Requires proper storage that can outlive a reset of SATOSA - Could be Redis, could be something else, abstract? Redis has a nice API and Graph database, but there are legal aspects to its licenses - Giuseppe shared an abstract storage layer example : https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/storage/db…. See line 18 - can use multiple storage engines. - Giuseppe also shared https://github.com/italia/eudi-wallet-it-python/tree/dev/pyeudiw - uses MongoDB by default - abstraction allows things to be "future-proof", but abstraction also sometimes prevents being able to use special features of a particular solution - Will also look at how to further separate the core: redoing some of the login work, enhancing the internals d. pySAML2 - https://github.com/IdentityPython/pysaml2 - upcoming release , then will continue with other open PRs - Nice work done regarding having configurable encryption algorithms: https://github.com/IdentityPython/pysaml2/pull/924 e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc) - djangosaml2 is stable; Giuseppe is waiting for revisions to be done that he asked for from developers - pyMDOC-CBOR - package was started to give guidance to the Italian community of developers implementing the wallet solution. The community has decided not to implement MDOC-CBOR for now, but it is a requirement so development will continue. - There was a new release of pyXMLSecurity; waiting for new release for pyff - try to discuss these next time 2 - AOB - Next meeting 26 September. Giuseppe not sure if he will be there. Thanks! Shayna Atkinson