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
*Attendees: Ivan, Shayna, Giuseppe0 - Agenda bash1 - Project review a.
GeneralGiuesppe discussed this wallet project for onboarding and trust
anchor demo: -
https://github.com/italia/spid-cie-oidc-django/tree/main/examples/wallet_tr…
<https://github.com/italia/spid-cie-oidc-django/tree/main/examples/wallet_tr…>This
is to be used in Italy with the OIDC federation for the two national
identity systems, SPID and CIE. This includes a quick tutorial on how to
get an entity onboarded, and also how to use customizable templates. The
good news in this project is that using federation for the wallets doesn’t
break anything with the federation - federation works as is.Giuseppe also
discussed this project:
https://github.com/italia/eudi-wallet-it-python/tree/dev
<https://github.com/italia/eudi-wallet-it-python/tree/dev>SATOSA is already
being used for the interop requirements between the vanilla saml2
implementation and the implementation profiles pertaining to SPID and CIE.
They have decided to implement a SATOSA backend on top of this to support
the implementation profile they have published :
https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/
<https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/>. In
the Relying Party Solutions section they give guidance about implementation
profiles and also some normative examples. This works with any SATOSA,
although they are forced to work with Giuseppe’s fork in Italy regarding
pysaml2 for the namespaces - since in Italy the namespaces are
normative.Ivan suggested having a more focused meeting between SUNET and
Giuseppe about these projects.Giuseppe and Roland have been talking about
the requirements in our community to have a credential issue in python. Is
there something on the way in the form of SimpleSAML frontend or django?
Ivan says they are in discussion with organizations like
https://github.com/sicpa-dlab <https://github.com/sicpa-dlab/> to be
aligned and move forward together. They have a big system with many
interfaces. The idea is to be aligned on the APIs. They have some things in
python re: credentials that we can use and then they will probably be using
the MDOC that Giuseppe has created. Ivan has been thinking about a
framework - using django is not a bad idea. It is much more mature than
other choices. He has been thinking about using django in general as a base
for SATOSA. Giuseppe talked about developing djangosaml2 - he put out the
original release and it has grown to v1.7.0 (
https://github.com/IdentityPython/djangosaml2/releases/tag/v1.7.0
<https://github.com/IdentityPython/djangosaml2/releases/tag/v1.7.0>) with
little effort on his part. He credits django with increasing productivity
for the community working on it. Ivan says the hard part is compatibility
with what it is already there.
<https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-ref…>
b.
OIDC libraries - https://github.com/IdentityPython
<https://github.com/IdentityPython> (idpy-oidc,
JWTConnect-Python-CryptoJWT,
etc)https://github.com/IdentityPython/idpy-oidc/pull/72
<https://github.com/IdentityPython/idpy-oidc/pull/72>Refers to how OIDC
checks whether a call to a userinfo endpoint is correct/valid. In order to
call the userinfo endpoint, you need to have an access token that has at
least the openid scope. If the access token is valid (meaning it hasn’t
expired/hasn’t been revoked and has the right scope), you can invoke the
userinfo endpoint and get a response. Idpy-oidc checks an additional thing
- the date the authentication took place, which also has an expiration
time. This should not be done - the access to the userinfo should be based
only on the access token. This additional check breaks certain flows and is
against the spec. This PR removes that additional check. Should talk more
with Roland to get his thoughts. He and Giuseppe have been added as
reviewers. c. Satosa - https://github.com/IdentityPython/SATOSA
<https://github.com/IdentityPython/SATOSA>Ivan wants to make a new release.
Changes were discussed at last meeting. A new backend was introduced that
depends on idpy-oidc. The next step (after release) is to make the saml
parts optional (it’s possible Roland has already done this work). Some
classes will need to be moved. This can be problematic - we need to make
sure there are compatibility fallbacks when we move the base classes
elsewhere. Hopefully no one is using those classes directly. There are also
some smaller changes to be merged. They will be released after the release
with the oidc changes.https://github.com/IdentityPython/SATOSA/pull/441
<https://github.com/IdentityPython/SATOSA/pull/441> - Ivan has not had time
to look at this yethttps://github.com/IdentityPython/SATOSA/pull/435
<https://github.com/IdentityPython/SATOSA/pull/435> - complex MR about
addtng types and type information. This needs some more thought before
being pulled in. https://github.com/IdentityPython/SATOSA/pull/431
<https://github.com/IdentityPython/SATOSA/pull/431> - from Hannah about
logout. We should have a meeting to discuss this one alone. This introduces
a need for server side state. We will have to use something like Redis and
bind proper identifiers to the logout flow. Once we have that we can do the
same for the communication flows etc. Guiseppe brought up that SATOSA
already has mongoDB as a dependency even just for unit tests. Giuseppes’s
frontend (https://github.com/UniversitaDellaCalabria/SATOSA-oidcop
<https://github.com/UniversitaDellaCalabria/SATOSA-oidcop>) was migrated to
idpy 3 weeks ago and uses mongoDB in order to reuse an existing
requirement. There are some concerns about mongoDB’s limitations in terms
of license - it can be expensive. Its config is complicated. Redis seems
simpler. But we don’t have to choose - we can have an API to work with
both, the user chooses. There is some work around an API in idpy-oidc that
could be reused for this. d. pySAML2 -
https://github.com/IdentityPython/ <https://github.com/IdentityPython/>.
Pysaml2There are some MRs and PRs to look at but Ivan hasn’t had time to
look at them e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)No
updates.2 - AOB Giuseppe asked are there any resources or experience
related to our community about the implementation of second factor
authentication as a SATOSA backend.Ivan says Peter from DASI has done
something around this and others have also - Ivan thinks the
implementations use a microservice to contact a third party service and
have a flow with the second factor. There is an effort to address this.
The problem comes from licensing - AGPL licenses.Shayna adds this link to a
presentation done at Internet2 TechEx 2022 by Matthew E and Benn O
pertaining to using COmanage Registry, SATOSA, and Privacy Idea to
implement an MFA solution for access to SPs.
https://internet2.edu/wp-content/uploads/2022/12/techex22-info-sec-dynamic-…
<https://internet2.edu/wp-content/uploads/2022/12/techex22-info-sec-dynamic-…>When
are people available for the next meeting? Ivan is away the week before
the next meeting, so not much in terms of updates will be available;
Guiseppe has a deadline so will probably not be there.Thanks, Shayna*
Attendees:
Shayna, Matthew, Scott, Roland, Ivan, Heather
Agenda:
0 - Agenda bash
FYI - Heather will be dropping off organizing these calls and Shayna stepping up to fill the gap.
1 - Project review
a. General
eduTEAMS: there has been contact with GEANT working on technical docs and they will be helping with documentation for the front end. The team is also looking at connecting the front end (idpy-oidc) with a postgres database, and part of the database are the secrets for the connected clients. Team needs to properly hash the passwords before storing them. Also, have been seeing some strange behavior that has to do with how state is kept within the front end, but probably idpy-oidc. Should be having code that is loading in memory, but when we restart a node, the information is lost. Once that is solved, everything is in place for eduTEAMS code to go public.
Roland: when it came to storing info over time, decided nothing should happen by 'magic'. If you want to save something, you have to initiate that. If you don't do that, then nothing is stored. This was a design decision early on.
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc, JWTConnect-Python-CryptoJWT, etc)
Should be ready to merge the backend on Satosa.
• https://github.com/IdentityPython/idpy-oidc/pull/70
Roland is also looking at how to run without pySAML2 so he can run his tests. He is using pytest to find dependencies. That will happen after the backend is merged. Should we add a check at the top of a module to import something from idpy-oidc to see if that works and help check dependencies.
Roland is also starting to look at the wallet documentation. Will do some development to figure out how to make Satosa a credential issuer. All TBD.
• See also one organizations plans to implement: https://italia.github.io/eidas-it-wallet-docs/en/pid-issuance.html
c. Satosa - https://github.com/IdentityPython/SATOSA
• https://github.com/IdentityPython/SATOSA/pull/439
Plans to merge:
• https://github.com/IdentityPython/SATOSA/pull/440 (note, there are contradictions between different specs, and this reflects that. It's about handling duplicate query parameters which may be needed for one of the OIDC specs (where another spec says you shouldn't have duplicate query parameters)
• https://github.com/IdentityPython/SATOSA/pull/427 (fix AppleBackend)
• https://github.com/IdentityPython/SATOSA/pull/419 (Handle OIDC prompt together with SAML ForceAuthn and IsPassive)
• https://github.com/IdentityPython/SATOSA/pull/435 (Ft typing)
• https://github.com/IdentityPython/SATOSA/pull/431 (Introduce SAML SP-initiated Logout to SATOSA proxy)
Note: starting to apply black formatting and pre-commit configuration.
Ivan wants to focus next on the open PR of supporting base paths (https://github.com/IdentityPython/SATOSA/pull/405)
Updating the Satosa image on docker: Matthew is working on that this week.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
Longstanding issue around supporting Windows. There is a problem with how temporary files are managed in Python. The PR is a temporary workaround until future Python core changes.
• https://github.com/IdentityPython/pysaml2/pull/665
Also moving forward with updating the error URL
• https://github.com/IdentityPython/pysaml2/pull/898
And various smaller PRs for maintenance.
More work is needed on new extension points (see conversations in Slack on the #saml channel - https://identity-python.slack.com/archives/CNDLAURU7/p1688030949364249)
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
No updates.
2 - AOB
Note the new TIIME workshop (31 January - 1 February plus side meetings in Copenhagen) has a website: https://tiime-unconference.eu/
Thanks! Heather
Attendee:
Ivan, Heather, Scott, Roland, Giuseppe
Regrets:
Matthew
1 - Proposed project (https://github.com/IdentityPython/Governance/blob/master/idpy-projects.md)
a. https://github.com/peppelinux/pyMDOC-CBOR -> https://github.com/IdentityPython/pyMDOC-CBOR
See email to the idpy-discuss mailing list on 9 June 2023. We have strong support on the list.
Giuseppe is working on the 0.6.0 release; expects that to be done in a week or so. Goal is to make sure this is a tool that people can use without knowing Python.
There are still open questions re: mDoc vs VS and how that will play out in the EU Digital Wallet ARF.
This spec might be of interest (if only to make us all crazy) : https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/
See also: https://github.com/vcstuff
Note the Open Wallet Foundation has started holding meetings and has a task force focused on OIDC.
• https://github.com/openwallet-foundation/OID4VC-due-diligence-tf
Italian specification of the wallet:
• https://github.com/italia/eidas-it-wallet-docs/pulls
2 - Project review
a. General
b. OIDC - https://github.com/IdentityPython (idpy-oidc, JWTConnect-Python-CryptoJWT, etc)
Roland has been working on Satosa backend connecting to the OIDC library (a new backend using idpyoidc so Satosa can make client calls to OPs). When we get this module, we can start to look at logout flows. This will also relate to the browser changes and how cookies are effected.
Next step, wants to get SAML out of Satosa core (it has a dependency on pySAML). Also want to get rid of cryptodome (sp?) in favor of cryptoJWT. Concern that cryptoJWT may not handle certificates well. (https://cryptography.io/en/latest/x509/) Need to also determine where else cryptodome may still be a dependency. Would be nice to clean up that legacy.
Separating the core from the protocols is a good idea, so each protocol can be treated separately and libraries installed as relevant.
Suggest we move ahead with a PR for what Roland has worked on so far. Fully separating out pySAML will need to be treated as a separate effort that will require several steps.
There are older backends talking to specific services (facebook, github). It doesn't appear we need those specific connections any more. Should they be removed? We can remove the ORCID one; they are using standard protocol flows. Do need to check for the rest. They should be just a question of configuration not a specific module.
Roland has released 2.0 of idpy-oidc, which is what eduTEAMS is using. So, now eduTEAMS is (nearly) free to publish their frontend.
Note there is confusion regarding the older libraries. See https://github.com/IdentityPython/idpy-oidc/issues/53 . Ivan wrote a response, but if others have more to add, please do.
CZNIC is maintaining py-oidc. Roland will reach out and ask if they'd be interested in moving towards a more up to date implementation.
FYI: https://github.com/UniversitaDellaCalabria/SATOSA-oidcop/releases/tag/v2.0.0
c. Satosa - https://github.com/IdentityPython/SATOSA - v8.3.0 and v8.4.0 released
• nothing major; just pulled in a few PRs
• Will be focusing next on https://github.com/IdentityPython/SATOSA/pull/405 to allow a change of paths
• After that, will focus on pulling out the SAML dependencies
d. pySAML2 - https://github.com/IdentityPython/pysaml2 - also had a new release
• main change keeps us compatible with xmlsec1
• need to do some work around updating dependencies, possibly removing old dependencies such as cryptodome, and using as much as we can from cryptography
• Giuseppe has made a PR for proper GitHub actions to test things as they are committed. Need to include that to make sure the CI is working for both pySAML2 and Satosa.
e. Any other project (pyFF, djangosaml2, etc)
• djangosaml2 had two releases since the last idpy call. Now at v1.6.0. Now have a more granular control over samesite cookies.
3 - AOB
a. 2024 in-person meetings - https://github.com/fedidcg/meetings/wiki/2024-List-of-Identity-and-Related-…
Note that the next idpy call is scheduled for July 4. Ivan is available, though probably the US participants will be offline that day.
Thanks! Heather
