*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
Hi,
I am attempting to set up a SAML environment to better understand how
Satosa works. Here is the model of my environment: SAML Service Provider
(SP, pysaml2) <-> Satosa Proxy <-> SAML Identity Provider (IdP, pysaml2).
During the single sign-on service, after entering the username and
password, when the SAML IdP posts the AssertionConsumerService to the
Satosa Proxy, an error(satosa log attached) occurs:
'saml2.sigver.SignatureError.', the following is my satosa proxy logs:
https://pastebin.com/YsRMVzKD
I am unsure about how to resolve this issue. Could anyone provide me with
some guidance?
Any help would be greatly appreciated.
Thanks,
Sam
