Sorry, I left the wrong date at the top of the agenda for the idpy
developers meeting. It should say "Tuesday, 9 January 2024, 14:00 UTC"
Thank you,
Shayna Atkinson
SCG Consulting Group
Dear all,
I’m pleased to announce a long overdue update to the Docker Official
Image for SATOSA, which includes several significant changes:
- SATOSA 8.4
- Python 3.12
- Debian 12 “bookworm”
- Alpine Linux 3.19
The updated container image is now available from Docker Hub. For more
information, see https://hub.docker.com/_/satosa.
Happy holidays!
Matthew
--
"The reason that ed is the standard editor is to remind you that
things could be worse, and once were." -- Tim Lavoie in comp.lang.lisp
*Idpy meeting 19 December 2023*
Attendees: Shayna, Ivan, Roland, Matthew E.
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- idpyoidc 3.0.0 released
- openid federation implementation - Roland has openid4v (wallets) -
assumed openidconnect at base but it is oauth.
- Reminder that client registration information is not
well-documented.
- SATOSA container generates xml so that a newbie can get it going;
intent is to have a docker compose project that can stand up an oidc
environment and showcases all different integrations
- Roland has SATOSA OP frontend that is sort of based on Giusppe's
work, but partly new. He has the federation support. Didn't want to be
dependent on MongoDb, has persistence layers with store/fetch. Ideally
there is a function to register an OP (independent of backend).
- Ivan acknowledges that registration process is not well
documented and assumes pre-existing knowledge. Also does not have good
examples. He has not really used the dynamic registration,
but has used
static registration with the database for client data. He has used
different authentication methods for the clients: basic auth or client
secret post. Beyond that things get strange. Basic use cases
are there and
some advanced ones, but some may be missing. The problem is
there is not
just one level of documentation - are you a user, a
developer? Roland has
worked hard on base documentation for idpyoidc at
https://idpy-oidc.readthedocs.io/ but it needs to be updated.
This is for the library. The front end is one layer above and
we could use
documentation for that as well.
- openid federation adds a whole different layer to this. Clients
no longer register, they just become members of the federation.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Considering how to expose metadata in openid federation format
- Some work required before making a new release
- Need to pull in Roland's PR separating pyoidc and pysaml2 from core
- Looking at PR on plugin for getting session info from SAML
entities - but the project tries to keep plugins protocol
agnostic (this is
clearly SAML specific).
- This brings up: how do you map from oidc to SAML? Right now
claims and attributes are mapped; scopes are there but not
really reflected
in internal data. Acr claim and amz claim are also not
reflected in
internal data. Need a document on how to map between the
protocols and
derive the internal data. This is needed if we want to
extend the core with
more protocols.
- jwt token from saml transaction (there is a spec)
d. pySAML2 - https://github.com/IdentityPython/pysaml2
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- Matthew working on getting SeamlessAccess pieces into one
release-ready container. If you have feet in both oidc and SAML worlds,
how do you take advantage of scalable federations in both with a
consistent
user experience? He's been coming up with ideas mostly surrounding
mirroring in SATOSA, to expose oidc as SAML. It is tricky, treating the
oidc entities the same as saml identities.
- Discussion of how to handle this; pictures attached.
2 - AOB
- Next meeting 9 January and then every 2 weeks after that
Im looking on how to verify the in_response_to id of the authentication
response.
Most examples use allow_unsolicited to ignore this so it is a bit hard to
find good sources.
Many of those examples also reference to a "built-in cache for authn
request ids in pysaml2", but I can't find any usage of that anywhere.
I have tried to do this myself by just saving the ids I send to a
dictionary and then give them as a parameter
to parse_authn_request_response.
My question is this. How should this really be done? Is there a built in
cache or what is the recommended way of verifying the in_response_to ids?
Thank you
--
Stefan
Attendees: Johan, Shayna, Matthew, Hannah
Due to the absence of the key developers, we talked about Matthew's work in
python release engineering with gihub actions, and how we can potentially
improve the build process / user experience in deploying docker
container-based tools (in many areas, not just the idpy world).
Next meeting is 5 December 2023.
Attendees: Johan, Shayna, Scott, Ivan, Roland, Matthew E.
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc) -
- Roland updated fedservice library to work again after some changes to
idpyoidc
- Roland is also working on openid4v (OID4VCI and OID4VP) package
testbed or example that will contain the normal components in a digital
wallet ecosystem.
- https://github.com/rohe/openid4v
- This is a moving target with specs changing from day to day
- satosa_oidcop / idpy-oidc issue on slack - about being threadsafe,
secrets not shared between threads. Keys were created on startup and not
saved to mongoDb. The fix is to make the secrets static with example
configuration.
https://github.com/UniversitaDellaCalabria/SATOSA-oidcop/pull/47
- identity assurance support for idpy-oidc:
https://github.com/IdentityPython/idpy-oidc/pull/83
- also fixes some tests.
- Waiting for Kostis to look at it. Giuseppe has approved.
c. Satosa - https://github.com/IdentityPython/SATOSA
- preparing a new release - with new OIDC backend - requirement to pull
in idpy-oidc
- Next step is to work on Roland's MR (
https://github.com/IdentityPython/SATOSA/pull/442) removing SAML
bits, replacing encryption and signing with cryptojwt. Then
crypto will be
the dependency and pysaml2 will not be a dependency. That will be a
separate, major release since it changes the default
dependencies. Include
messages so that when someone tries to import a module / use a
frontend or
backend without pulling in dependencies, they will get an error message.
- after this, consolidate SAML logout and OIDC logout
- Should think about introducing server side storage
- sql? One problem is manual cleanup required. But it is more clearly
defined.
- More specific to sessions - redis? Cleanup is handled nicely but
licensing may cause problems for some. It is "almost open
source". If it is
used in a commercial product under certain conditions, then
there is an
issue.
- Matthew prefers pure opensource solutions. Sql database helps
with clearly defined schema. Non-sql is hard to figure out.
- He has struggled with oidc figuring out how to do static
registration.
- Need to define the interface and define types - class that
defines how payload looks.
- There is also a documentation issue - someone who is
knowledgeable but new can't figure out how to do some
simple things. As
new things are developed and decisions made, Matthew will
help with the
documentation.
- Bottom line -the data model is missing.
- https://github.com/IdentityPython/SATOSA/issues/445
- passed on to Ali - concerns existing implementation of pyop and
some work that Ali had done
- Not sure if they will continue to do an work on pyop.
- There are other openMRs that need follow-up.
- Typing from Fredrik and Johan is still waiting - will get to it
after next release.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- Fixing MR/PR issues regarding changes in the modules and dependencies
used. Things like the python version changes, modules change
behavior, etc.
- https://github.com/IdentityPython/pysaml2/issues/917
- https://github.com/IdentityPython/pysaml2/issues/904
- https://github.com/IdentityPython/pysaml2/issues/934
- https://github.com/IdentityPython/pysaml2/issues/921
- user gets a response from idp - with attributes - one defines type
of value of attribute - within the type it mentions a prefix.
Prefix is
defined with an xml namespace. This is called QName
-awareness. The built
in xml parser removes the namespace.
- xsi:type - python parser is not QName-aware
- xpath - c implementation that python uses. Smaller than lxml
but limited.
- this can be fixed by using lxml, xml library with c-bindings,
but it also adds other issues and complexity. Has to be configured
correctly. To make this a compatible change is not easy.
- there is also a schema checker that may be of help. Ivan will
check with the developer.
- Ivan could make lxml an optional dependency.
- Ivan has done half the work but he is concerned about whether he
should invest more time.
- A fundamental issue is that python garbage collection does not
work well with C layer memory management. Deployers using
SATOSA with that
library would need to restart their servers frequently. For
example pyff ,
which uses lxml, needs to be restarted hourly in a production
Scott has.
- https://github.com/IdentityPython/pysaml2/pull/924
- need to get to this one - to configure the encryption algorithms.
Same should be done for signing algorithms.
- Issues around how temporary files are deleted - mostly affecting
Windows users. Proposal on how to make it independent of
platform. Usually
these temp files are certificates or templated xml that will be signed.
Ideally we could work in memory for these types of things.
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- Leif made two new pyff releases - 2.1.0 and 2.1.1. We should get him
to summarize the changes for us.
- RDCT/SCG is making a standalone seamless access deployment, using
pyff, thiss-mdq and thiss.js . Once in production it will be
packaged up in
a reusable way for others to deploy. Arlen Johnson is working on some of
the packaging and Hannah S will work on an all inclusive docker compose
project. Generalizing to contribute to docker official images library or
something similar.
2 - AOB
- Next meeting is 21 November 2023. There is a wallet meeting that day
but it is scheduled to be done by the time of this meeting.
