10:09 p.m.
*Idpy meeting 23 January 2024*
Attendees: Johan W, Shayna, Ivan, Matthew E.
0 - Agenda bash
1 - Project review
a. General -
We would like to get Roland to do a demo on his wallet system. There is
great interest about the trust within the system, the issuers, the
credentials, etc. Shayna will message him about scheduling it.
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Focus is currently on projects around oidc that implement the wallets.
- version 3.0.0 of idpy-oidc was released 17 December.
- side news - Christos is creating a repo to host GÉANT Core AAI
frontend, which is based on idpy-oidc. The main component is
SATOSA - this
will happen soon.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Repo needs to be cleaned up. Some things have been merged but no
release. After cleanup, Ivan needs to add dependencies for oidc
backend as
an extra requirement (optional dependency).
- Other PRs that are pending to go in:
- Roland's work on removing SAML parts -
https://github.com/IdentityPython/SATOSA/pull/442 -
- Pavel's PR - https://github.com/IdentityPython/SATOSA/pull/419
- Johan's PRs - https://github.com/IdentityPython/SATOSA/pull/449
and https://github.com/IdentityPython/SATOSA/pull/450
- Ivan is looking at these Metadata PRs -
https://github.com/IdentityPython/SATOSA/pull/438 and
https://github.com/IdentityPython/SATOSA/pull/448 - Ivan has some
issues with these - there is a better way, using this (metaform) instead
as a base : https://github.com/SUNET/swamid-satosa/tree/main/src
- 438 is getting info from oidc services to be accessed by user -
denotes different metadata in terms of language in a specific
way, which is
also something that the oidc standard specifies. It's a nice
notation that
gets us away from having to nest things based on a language signifier.
Instead, this uses display name of a service with a language
tag - default
(no language tag) is english. Only does this for some
information, but more
would be useful and there will be some work to accommodate that.
- 448 - work is from Vladimir in NZ- mixing attibutes for person
with the metadata, because there is no other place for this
information. A
new slot should be dedicated for this information. Also there is some
information such as display name, scopes, etc., that is
implied to be about
the IdP, but it could be about the SP - there is no
indication where it
came from. The idea is to have a dedicated slot - not mix
things with the
attributes of the subject, and then under its own key also
have info for
the service AND for IdP. Then everything is separated and
made clear. And
then we can denote the languages with the notation from 438
(inherited from
oidc spec). Can be based on metainfo (see above) which has
collators that
work with both SAML and OIDC. For OIDC it is implied there is a data
structure - someone who has statically registered the client
would need to
add this data - it is not part of the official spec.
- Discussion of using Scott K's attribute store plugin response
microservice for IdP metadata attributes. It pulls from
metadata store in
the context. Be careful if you redirect - the object with the
information
will go away. Part of the reason Ivan would like proper
server side storage
for the proxy is that some federations may have many scopes
for their IdP
which creates a huge payload, and if you grab the metadata
from this object
and try to put it in a cookie, it is too large.
- Ivan would like to make this part of SATOSA, not just a
microservice, so not just attributes of user are available,
but also of the
service and the issuer. This will require proper APIs for
both the backends
and frontends, to get the data in a specific, defined format.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- Some updates need to be done for dependencies - there will be a new
release to accommodate these things
- cryptography has a new version
- cryptojwt
- xmlschema - new version/release is breaking APIs that are
currently being used.
- Fixing datetime() calls for python 3.12 as they are deprecated
- Get back to configurable encrpytion algorithms / signing
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- djangosaml2 - possibly looking to add new logging calls to do
tracebacks?
- thiss - working on container to get readymade setup
- Matthew E. is also trying to get an all-inclusive seamless access
deployment working, and once they do they will contribute their
containers/changes back to the community.
- His goal is to create a docker compose file that others can use,
using as a default eduGain metadata, to get their own seamless access
working. Then put pyff, thiss-mdq and thiss-js in the docker official
images library to get regular rebuilds for security updates
and follow good
current practices for containers.
- Johan may be able to share something with Matthew from his own
deployment, for smaller federations. They restart pyff
service every 15
minutes to reload metadata.
- pyff can be used two different ways: as a service, or as a
process that runs once and processes metadata, spitting out
xml files for
you, along with a json feed which can be used by
thiss-mdq/thiss-js. There
may still be a memory leak in the service variant?
- SWAMID is wanting to get a new release of pyff - there are some
small commits to HEAD that they need.
2 - AOB