*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.
Hello,
My name is Felipe Cardoso and I am part of the IT team at LIneA
(Interinstitutional e-Astronomy Laboratory). LIneA is a non-profit
organization that operates in the international academic ecosystem,
supporting Brazilian participation in astronomical surveys and managing
large volumes of data.
Currently, our infrastructure includes services that are integrated with
authentication mechanisms such as social login (Google, Github, CILogon)
and federated login (SAML) through an instance of the SaToSa proxy. In our
case, we have some services that implement SAML, and thus we use the SAML
Mirror frontend plugin to allow the mentioned authentication backends to
serve the services' users.
We would like to implement the concept of Single Sign-On (SSO) in our
services, but we are facing challenges due to our limited knowledge of
SaToSa. Could you please inform us if it is possible to configure SSO
functionality in SaToSa? Additionally, is there anyone with a similar
scenario to ours who could provide guidance on the way forward?
Felipe on behalf of LIneA IT Team
*Idpy meeting 11 June 2024*
Attendees: Johan L, Shayna, Ivan
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Roland has opened an PR - it fails one of the tests
- https://github.com/IdentityPython/idpy-oidc/pull/104
- https://github.com/IdentityPython/idpy-oidc/issues/106
- A claim that is expected to be returned is not coming back
anymore.
- Not understanding why this is happening
- Is the test actually a requirement of the spec, or just
something the test assumed would be there?
- This PR addressed changes required to align with the PAR (Pull
Authorization request) rfc
- RAR (Rich Authorization request) allows you to define more
things happening during the authorization phase
- Have pinged Roland but haven't heard back. If Ivan has time he
can also look into this.
- New PR - https://github.com/IdentityPython/idpy-oidc/pull/107
- Allowing variable ports for native oidc clients or RPs when the
redirect uri is the literal localhost - the actual IP ( IPv4
127.0.0.1 or IPv6 ::1 / 0:0:0:0:0:0:0:1)
- spec says native clients, when they start an authorization flow,
they do this through the loopback interface and bind to 127.0.0.1
/ ::1 and can use any port available. The port is decided
directly by the
platform and the client does not have control of that.
- requests are forwarded to the auth server with the port assigned
by the system
- This PR allows variable port exception for native clients
- introduces checks around redirect uris - they become part of the
location header - they are URLs and not uris. They can have
other schemes.
The python library doesn't do certain validations so they
have to be done
manually around this uri (which is a URL) - scheme:
path/domain/valid port.
- This PR bound to http URLs
- There is further work to be done to filter out certain schemes
for the redirect uri that wouldn't make sense in this case
and could be
dangerous. Ivan will make an issue for this.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Ivan is supposed to create a new release-hasn't done yet.
- Matthew needs to update image around missing SAMLtest ID - he's
probably waiting for Ivan's new release
- updates on pyop to start deprecating-
https://github.com/IdentityPython/pyop/pull/55 -
https://github.com/IdentityPython/SATOSA/issues/445
- pyop provides interfaces that are useful also for SATOSA.
Support was added in pyop for stateless flows - all the
state kept in
tokens. There are limitations to this - there is a size
limit - but it does
allow no need for a db and keeping state. Another drawback
is you can't
tell when token has been revoked.
- when the code was introduced it broke another part, having to
do with the claims from the user info endpoint.
- Fix is to bring back the old flow and make an exception when
in the stateless mode.
- this MR will be merged and new pyop released but really pyop
should be deprecated. There should be amendments to the
Readme pushing
people toward idpy-oidc. Already have a SATOSA backend
using idpy-oidc.
Don't have support for a frontend using idpy-oidc. There
is the work
Giuseppe has done which we already point to. We are not
removing pyop but
saying that the focus is somewhere else.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- Johan's PR - https://github.com/IdentityPython/pysaml2/pull/964
- Big divide in security domain
- make things configurable - this is what xml dsig/encryption is
about - but as you interoperate with others it makes
updating difficult.
- OR everything should be pinned down to very specific things -
no random lengths of keys, no random types of keys, no
random algorithms
etc. Everything is specified and there is only one way to
do things. If you
pick the right things, you are future-proof. This is what
signal is about.
- Add xenc schema 11 to code base.
- pysaml2 added support for xmlsec binary
- frederik's MR about typing is related to this -
https://github.com/IdentityPython/pysaml2/pull/897
- Ivan will merge Johan's PR (964 - need to also check whether
anything is needed to support newer version of xmlsec1) and
make a release,
then merge PR 897 to unblock Johan, then get back to 961
adding support for
xmlsec module https://github.com/IdentityPython/pysaml2/pull/961
- Also need to make sure xmlsec module doesn't need lxml
- a few annoying things: xmlsec module defines its own types for
handling keys and certificates, then there is another type we
define based
on pyOpenSSL, then there is another type from
pyca/cryptography - just keep
having to convert from one type to another.
- xmlsec1 - C libraries - had to provide specific constraints to
restrict xmlsec from going out to the web to fetch keys or metadata or
other interfaces to do calculations. Ivan is pretty sure
xmlsec module is
doing the same thing,
- also would use signing key from within the SAML response itself
instead of key extracted from the metadata
- We have tests for the binary - make sure they also work with
xmlsec module, then limit functions in code
-
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- work on pyff around supporting trustinfo elements - spec stems from
seamlessaccess - they indicate certain IdPs are preferred over the rest -
you can say you only want to select from those - they can be
highlighted or
ranked first, for example. There can be complex rules indicating
preference
of sets based on assertion authorities or other things.
2 - AOB
- Ivan will be away 25 June. Will check with Roland for his availability
and determine if meeting will happen.
Notes from Ivan:
For idpy-oidc, work is being done around the support for native clients,
especially supporting variable ports for redirect URIs.
Along with that work, more checks are added around the validity of a
redirect URI. The redirect URI should be a URL as it will become part of
the Location HTTP header. The standard python libraries (urllib.parse) do
not perform any kind of validation and will even accept ports with letters.
Additionally, we need to properly check for the URI scheme. I'd like us to
have a denylist (or an allowlist) for schemes. Schemes like "data://" and
"javascript://" should be denied.
On another front, I have been working to generate test data with the Faker
library. It integrates with pytest too. We can use that library to generate
randomized data that follow some specific format. Given a seed, we can
recreate the same data. A few useful references here:
- https://faker.readthedocs.io/
-https://faker.readthedocs.io/en/stable/providers.html
-https://faker.readthedocs.io/en/stable/communityproviders.html
Matthew brought up the topic of tidying up the satosa repo. This relates
to https://github.com/IdentityPython/SATOSA/pull/454. We agreed to separate
the configuration changes from changes after applying the settings (big
changes on the source code etc). We should agree when to apply the changes;
certainly after the new release that is to come.
