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.
*Idpy meeting 10 October 2023*
Attendees: 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)
c. Satosa - https://github.com/IdentityPython/SATOSA
- Everyone who had attended the SATOSA PR-431 SLO review felt it went
well. Matthew E. was encouraged to see that limitations to pysaml2 were
acknowledged. Shayna will reach out to Ali H. for updates on when he
has/will push his changes so he and Hannah S. can collaborate on a vision
for single logout.
- Matthew E. is working on SATOSA container - he knows the current one
is out of date. Ivan merged some changes on pyop and Matthew has a better
understanding of the newer oidc libraries, so he wants to come up with a
working test config for oidc and include it into the sample configuration
of the container. He is not sure where to find a test OP.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
2 - AOB
- Next meeting is 24 October 2023.
