Attendees: Giuseppe, Ivan, Johan, Matthew, Hannah, Shayna
0 - Agenda bash
1 - Project review
a. General
Review of Matthew E's
pull request 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.
"pyop_mongo": ["pyop[mongo]"],
"pyop_redis": ["pyop[redis]"]
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.
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.
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
abstraction allows things to be "future-proof", but abstraction also sometimes prevents being able to use special features of a particular solution
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
Thanks!
Shayna Atkinson