*Idpy meeting 20 November 2024*
Attendees: Johan W, Johan L, Shayna, Ivan, Roland, Hannah S, Ali H, Mikael F
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Roland's big PR - lots of changes to idpyoidc. He will divide into
smaller chunks and issue as PRs.
- upcoming work on audience policies - GRnet
c. Satosa - https://github.com/IdentityPython/SATOSA
- Ivan has prepared new patches/releases - haven't posted but has the
tags locally. Will announce on slack when the new version is available.
- plan to merge in stages
- Ivan has been getting requests to easily setup an environment to
run satosa and run it locally. He has been thinking about doing something
similar to the reflector backend (the reflector backend, instead of going
out to a actual idp, immediately creates a payload and returns a
response).
To start the flow we need a service - create something like the reflector
backend which will act as a frontend. It will directly trigger a
flow when
you try to access it, and once it gets a response it will just show the
response. Then we don't need to involve any other service that acts as an
SP or IdP. Can configure how we want IdP to behave. Frederik from Umea
Universitat - plugin that displayed a page and allowed you to insert your
own values for attributes; it also created several profiles.
Would like to
try and build on this.
- Single logout discussion with Hannah Sebuliba
- Met with Ivan and Ali in January 2024 to try and merge the work she
had done into Satosa. There are some conflicts and Hannah would like
guidance how to proceed.
- In provious discussions, the recommendation was to hide the
single logout capabilities behind a flag in order to control
when they are
enabled, so that changes will not affect existing workflows.
This allows
merging without breaking, and testing and testing and fixing
things as we
go along. Then when everything looks good, either remove the
flag, or keep
it so people have the option to enable or disable the feature.
- Important to document what the new features are - what bindings
are supported, what the checks that are implemented actually
do, verify
messages, signatures, and identifiers within logout request
and response
messages.
- The most important thing is to record what we do with the state.
To support logout we need to keep state, The state has to do with the
sessions, the identifiers of the users, and the identifiers
of requests
that came in and correspond to the logout message. Also
allows us to avoid
attacks where someone could send logout requests using an
identifier they
found somewhere.
- It would be good to update the state diagrams
- Hannah felt an important idea was to move the session handling
to SATOSA rather than SAML ends - this is under discussion
- Ali's work has the storage within SATOSA - some parts of the
storage are in the frontend or backend. There is a map
between frontends
and backends connecting the session. The logout request should not be
specific to only one protocol. This required the session to
be kept within
SATOSA. Currently Ali's work supports Postgres. Can add other
adapters.
Also has the logout enabled flag.
- There are differences in the work Ali and Hannah have done, not
just the protocol but also the flow itself. Hannah has worked on SP
initiated logout - with SAML SPs and only logs out SAML IdPs.
It will not
log out OIDC-based IdPs. Ali worked on the OP initiated
logout. Even so,
the requirements and the state that needs to be kept are very similar.
- Need to get back to original code and review it. Should be able
to merge PRs independently, as long as they are behind the
feature flag.
Storage - abstract managed by the proxy and not related to
the protocols
directly. This will add some complexity before and can be
messy. Ivan is
not totally sure this is the right way. If code is kept
isolated, should
work.
- There was some discussion on 1) whether the flag should be the
same or separate for each protocol. Ivan seemed to think it
should be the
same overall. 2) Whether the logout should work for both protocols (no
matter which protocol initiates the logout, SPs and IdPs from both
protocols are logged out). Ivan thinks eventually it should
work this way
but initially each developer should focus on the protocol
they have been
working with.
- Hannah asks are there any services to use as test RP/OP? At one
time Ivan had done someting simple with Apache module -
modauth openidc
https://github.com/OpenIDC/mod_auth_openidc. Ivan doesn't think
she should worry about that right now. Merge the initial
patches and then
worry about oidc.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- new release coming that will allow filtering of idps based on trust
authority. Discovery service parts are being tested right now.
- two phases - information processed by pyff - produces artifacts
that are fed into thiss-ds and are searchable by users.
- maybe there can be an information session on this during a
future meeting.
2 - AOB
- Roland has big demo on digital wallet coming up in Paris.
- He has created a document with Giuseppe about profiling the federation
specification.
*Idpy meeting 6 November 2024*
Attendees: Johan W, Johan L, Shayna, Ivan, Matthew E.
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- error handling of certain requests, for example, refresh token grant -
refresh token param was missing, fixed now and merged.
- new capability to set lifetime of id token per client has also
been merged
- more fixes for resource indicators specification limitation will
happen soon
- might add hook to change responses in case there is a need to do
filtering or add more data to responses outside of idpy-oidc,
for example
information stored in remote databases; remote data providers.
- Roland is working on another big PR through his work on wallets.
- Ivan worked on pyop to include the latest MRs for new release
(released 3.4.2)
c. Satosa - https://github.com/IdentityPython/SATOSA
- creating a new release with what is there now and then continuing with
the plan that has been set out, merging MRs and releasing in stages
(plugins next, then typings of entity categories, etc).
- update image after release - taking out all of the samltest.id
configuration.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- No updates
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- new release of pyff imminent?- trust info profiles- corresponding
updates on thiss-mdq. Mykal Frykholm will be working on pyff
maintenance
more.
2 - AOB
- Single logout to be a focus of next meeting on 20 November (involving
Hannah, Matthew and Ivan).
- invite Mikael Frykholm to these meetings
Attendees: Johan W, Johan L, Shayna, Roland, Hannah S
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Roland has been working with digital wallets - changes in idpy-oidc
- assumed identity had one role at a time, but openid federation does
away with that - can be many things at the same time - e.g.
oauth client
and oidc RP at the same time
- had to go back through code to cope with this - especially when
dealing with metadata, registering what happens in both the
cases above;
how to deal with registering both with an AS and an OP (how
to deal wth
things like provider information)
- changes in wallet system creates changes in the foundation
- At the end of November, there will be a demo in Paris with
social security information - 10 different countries will all
be demoing
the same thing. One wallet, 10 different information providers.
- starting today they are to deliver docker containers
- they will set up trust layer/wallet provider - Greek wwWallet
- built in cooperation with gunet, sunet and yubikey
- Germany is participating - they are not fond of openid
federation and want the trust layer to be different.
- Sweden is not involved.
c. Satosa - https://github.com/IdentityPython/SATOSA
- SATOSA doesn't always do what Roland expects as he's working with it
- Hannah would like to get Single logout back on the front burner and
figure out logistics between herself, Ali, Ivan and Matthew to make it
happen.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- Mikael Frykholm from Sunet is working to take over as program manager
for pyff.- a new release is expected soon.
- Roland plans to retire at the end of this year - there is work to
gather people to take over his work.
2 - AOB
a. New time - Wednesdays at 7:00 am Eastern time. Need to make sure this
does not conflict with the meeting that Johan L, Johan W and Ivan have with
Leif on the last Wednesday of every month. Next meeting will be 6 November,
then every two weeks through the end of the year. Will restart on 8 January
in 2025.
Sorry for the delay in getting these out.
Attendees: Johan W, Johan L, 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)
- Roland has merged some existing MRs, including:
- Comparing uris for auth and oidc RPs and clients - special handling
defined for oauth native clients (application on a mobile
phone or on a
computer - not web application).
https://github.com/IdentityPython/idpy-oidc/pull/107
- Pending MR about resource indicators which will be updated
again. RFC defines how token that is generated through an openid
flow will
be used by a specific target. Work is finishing up on this.
https://github.com/IdentityPython/idpy-oidc/pull/102
- The effect is that the token will have certain audience values that
have been requested, but there are many cases where you need to apply
policies about which client requests can access certain
services, and this
may also be combined with scopes, limiting what you can ask
of a service.
Audience policies - how you can specify how the relationship between a
client, servives and scopes actually works. This is different
from how you
request a specific audience to become part of a token. There
is no PR for
this but there are discussions going on how it should be implemented.
- idpy-oidc -native clients can request different schemes - the
control is given back to the application rather than the browser. More
policies and configurations for these kind of things are coming.
- Roland has been working on wallets on his own fork of idpy-oidc and
sending back updates.
- new release for pyop - still in use but will be slowly deprecated.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Ivan has been working on other projects
- will be backporting things that were added for EOSC
- will be merging things, creating smaller releases.
- some work on pyop, anything easy on pysaml2 and satosa
- PR-396 <https://github.com/IdentityPython/SATOSA/pull/396> is
part of a series of PRs created by Sven Haardiek
<https://github.com/shaardie> around ldap_attribute_store
(395-398). Ivan will go ahead and merge all of them. 398 was
trickier but
Ivan will test and merge if it doesn't break anything.
- Should create a ticket to add tests - going to go ahead and
merge because they are an optional microservice.
- Kristof wants his MR merged - support for path elements in the
base url of satosa - will probably talk more about that.
- Matthew's MR https://github.com/IdentityPython/SATOSA/pull/454 -
maybe take this into account for AOB below.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- In the same state as satosa above
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- pyff - Leif did a few merges. Work around trust info specification -
working group around this and to rename it.
https://github.com/IdentityPython/pyFF/pull/271
2 - AOB
- Matthew previously talked about a POC for code style and github
actions - he now has an intern that will be working on this -
- would like to pick a relatively smaller library, maybe pysaml2, and
provide a POC in a branch which will be reviewed in November
so the intern
can get feedback. Matthew had suggested Python black for code
style, using
pre-commit to do the checking, running out of github actions so that
linting and tests would happen automatically on pull requests.
- From Ivan:
- We have some things already but they do not run automatically.
So we have a basis but it can be extended.
- On pysaml2 we have a few relevant MRs:
- https://github.com/IdentityPython/pysaml2/pull/882
- https://github.com/IdentityPython/pysaml2/pull/816
- We also have a devs guide
-
https://github.com/IdentityPython/pysaml2/blob/master/DEVELOPERS.md
- and linters configured:
-
https://github.com/IdentityPython/pysaml2/blob/master/pyproject.toml#L200-L…
- Let's do this in a way so that it can be inherited by
other projects.
- Roland would like to find a new time for this call.
- Shayna is sending a doodle poll.
*Idpy meeting 3 September 2024*
Attendees: Johan W, Johan L, Shayna, Ivan, Hannah S
0 - Agenda bash
1 - Project review
a. General - Ivan's plan is to merge things that don't break anyone's
flow.
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- pyop - there are some changes that can go ahead, won't block anything.
and then there will be a new release -
https://github.com/IdentityPython/pyop/pull/55
- plan is still to move away from pyop, however
- more patches coming up for idpy-oidc - internal repos so no PRs.
- configuration change needed to handle redirect uris better- read
urls with special characters like spaces work with some flows
but not for
others.
- reuse indicators - there are specific use cases as to how they
are to be treated and that has been encoded into tests -
later on the code
changes. Separating what happens when reuse indicators are in place in
regards to token exchange - the two specs reference each
other but also
conflict in some ways.
- introducing new concepts around audience policies
- mechanism that allows you to state an audience
- what requirements you have for the audience. Allow multiple
values, one value, etc.
- This has nothing to do with reuse indicators where you signal
which value or values should be set as the audience.
- There are also some questions as to how things work and when
resolution takes place based on different layers - you
could request
resource X and this means the audience will get service 1
- the identifiers
can be different.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Anything behind a features flag can probably be merged, such as the
logout capabilities that Hannah S and Ali have been working on.
- logout PRs that can be merged -
- https://github.com/IdentityPython/SATOSA/pull/444
- https://github.com/IdentityPython/SATOSA/pull/431
- backend/frontend connections - need some discussion - complex
- https://github.com/IdentityPython/SATOSA/pull/449
- https://github.com/IdentityPython/SATOSA/pull/450
- These will be easy to pull in:
- Apache configuration:
https://github.com/IdentityPython/SATOSA/pull/462
- Tu Wien SP configuration example:
https://github.com/IdentityPython/SATOSA/pull/469
- EntraID backend:
https://github.com/IdentityPython/SATOSA/pull/461
- documentation cleanup:
https://github.com/IdentityPython/SATOSA/pull/458
- xmlsec breaking:
https://github.com/IdentityPython/SATOSA/pull/452
- dev processes - pre-commit and flake:
https://github.com/IdentityPython/SATOSA/pull/454
- a bit harder:
- types - needs thought but can probably move forward-
https://github.com/IdentityPython/SATOSA/pull/435
- removing pyoidc, separating dependencies between SATOSA and
pysaml2 - this is a breaking change; this will require people
using SATOSA
to install pysaml2 separately now
https://github.com/IdentityPython/SATOSA/pull/442
- more involved:
- Kristof - base paths - need to make sure we're not breaking
anything. Paths that were there before should still just work.
https://github.com/IdentityPython/SATOSA/pull/451
- adding new member services - exposing information - needs to be
done a different way.
https://github.com/IdentityPython/SATOSA/pull/448
- LDAP plugins - add tests - not pressing, on hold
- backend and frontend names are unique - this PR should go in but not
in the suggested format.
- d. pySAML2 - https://github.com/IdentityPython/pysaml2
- To be merged:
- xmlenc: https://github.com/IdentityPython/pysaml2/pull/964
- EC types: https://github.com/IdentityPython/pysaml2/pull/897
- MDQ: https://github.com/IdentityPython/pysaml2/pull/959
- domain validation:
https://github.com/IdentityPython/pysaml2/pull/951 - needs a few
changes, then will be easy to pull in
- UTC https://github.com/IdentityPython/pysaml2/pull/939 - can go
in with a little bit of checking
- Windows support - these will probably be closed and done differently -
maybe using signals from garbage collector cleanup would be better as a
workaround? Really needs to be addressed by Python itself.
- https://github.com/IdentityPython/pysaml2/pull/933
- https://github.com/IdentityPython/pysaml2/pull/931
- https://github.com/IdentityPython/pysaml2/pull/665
- important: encryption algos:
https://github.com/IdentityPython/pysaml2/pull/924 - this one needs
to be checked - cannot just be merged
- dev processes -these will probably be merged - run tests when there is
a merge request opened; release packages when merge request is
merged. etc.
- https://github.com/IdentityPython/pysaml2/pull/882
- https://github.com/IdentityPython/pysaml2/pull/816
- lxml: https://github.com/IdentityPython/pysaml2/pull/940 - not
complete - it is a draft. It is a basis for using lxml everywhere in the
project. Lxml parser is Qname aware - it knows when an xml attibute
contains a namespace or a type. The default python parser does not do
anything with namespaces, so when you try to do validation, the namespace
is missing because python has optimized it away (removed it). There are
certain use cases where this is problem. Ivan may also talk to a
person who
has an xml validator which has a way of using the default python
parser but
still is able to check for those edge cases.
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- question on slack concerning pyff from Hannah at CERN. Ivan will try
to get to it today.
- PyFF - Ivan needs to look at this issue:
https://github.com/IdentityPython/pyFF/issues/264
- pyff - mdq - Ivan would like to have a configuration that says
output should go into either the file system (what happens now), or into
S3, or into a database (in which case you don't need a Discovery Service,
everything can be an API call). In the database case then things can be
quickly sorted and indexed the way you like. The problem is there is no
mapping between xml and a table. Need to think about how to do indexing
without the schemas, and so on. This will unlock capabilities
that we don't
have right now and also simplify what we do with the discovery service.
- Also need to change the way we parse xml into memory - can do this
within the entities descriptor. This shouldn't be hard. This
would make it
so we don't need a big machine or lots of resources to do the
parsing of a
large thing every 6 hours. Pyff could be put into a lambda, possibly.
- Or using S3 could make this a serverless process.
- SATOSA itself can also be simplified, but the whole
configuration would need to change. They have looked at moving toward a
framework like Django - not sure if this would be done as SATOSA
or SATOSA
version 2? New approach in parallel with what we have now - does
that make
sense time-wise and maintenance-wise? How to do this without
breaking what
is there now? Need to experiment with Django. Async parts of Django would
make some parts of SATOSA easier. Background things like statistics that
don't need to interact with the actual flow but need to be there
- perhaps
API call to elasticsearch to record that a new flow happened. Open
telemetry - asynchronous calls to the logger - tracing - do
these in a way
that don't affect the timing of the flow itself.
2 - AOB
- Ivan is doing a lot of work on EOSC with the AI integration.
- Next meeting - 17 September. Shayna will not be available but will
send out the meeting reminder. Ivan will take notes and send them to Shayna
to distribute.
