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.
*Idpy meeting 14 May 2024*
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)
- a while ago: demo of digital wallet ecosystem
- Roland was asked what would an identity federation look like using
the same type of setup? Roland has something running. Will
allow a person
who wants to see what the federation is to grab a number of
docker images
to run their federation. Roland is working on the recipes for
this, but
someone else is making the actual docker images.
- digital wallets - Roland set up an experiment - wallet connects
to SATOSA frontend credential issuer, gets redirected to backend
to talk to
SAML Idp, which returns attributes. Then when the wallet connects to the
credential endpoint, it gets a credential with the attributes
that the SAML
IdP released.
- requires persistent storage for the attributes - when you get to
the credential endpoint, SATOSA frontend doesn't know
anything about them
otherwise
- when the wallet asks for information, it is expected to provide
a credential type (personal, DL, etc). Discussion is going on about
specifying credential types that eduGain returns. Could ask
for a specific
type of information - such as higher ed - i.e. affiliation
(not things like
courses, degrees)
- Roland asked about this (credential types) in Slack - Ivan asked
if we know what the payload looks like? - not yet. Still
under discussion.
- Ivan is looking at native oidc clients - spec says "when this
uri is met, this application opens". When uri is localhost and it is a
local client, the port number can be anything. In oidc we check
for a port
exact match. This needs to be fixed - Ivan will describe it in an issue.
Breakdown uri into parts, sure make domain is correct, make sure path is
correct, but port....
- During oidc registration there are references to this claim which
is the client type option which separates confidential information from
public clients. But some people are using it to say this is a native app,
or a web application. The convention seems to be that native clients are
public clients. This is still a mystery - what this client type
with native
means, and web.
- Nikos PR *Draft* - resource indicator, how and when we set the
audience in generated tokens
https://github.com/IdentityPython/idpy-oidc/pull/102
- Roland also has a PR
https://github.com/IdentityPython/idpy-oidc/pull/101 - import export
module - now works for the complete application structure. Ivan
will review.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Kristof - meeting to close off PR about the base url that can be used
- lots of pending things and things to be fixed.
- Ivan wants to make a check for the optional dependencies and then
put out a new release, then move on. Approximate timeframe - hopefully
within this week.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- A new PR https://github.com/IdentityPython/pysaml2/pull/961 - uses
xmlsec module instead of xmlsec1 binary. Created new crypto backend -
extended pyxmlsecurity to do encryption with xmlsec module.
Could be a new
crypto backend and could also do the signing - can xmlsec module do the
signing directly? Possibly use this to replace xmlsec1 binary.
Issues with
xmlsec1 binary after version update - had to do updates on our side to
parse output as the outputs changed. The module takes care of this. There
are a few tricky things:
- xmlsec1 binary - command line options in place to not do any
additional stuff like going out to the web to find
certificates. Some of
these options are missing in the module. We want to make sure
it uses the
cerificates we provide and not something else. Within the xml
payload there
is a certificate and this is the one used instead of the one from the
metadata.
- Matthew question - xmlsec module - is it python standard or
third party? Answer - third party. How well has this been
tested? Xmlsec1
is battle tested. Ivan - it is C bindings for the xmlsec library.
- Tricky thing in pysaml2- have to specify a file in a filesystem.
Serverless use cases where that type of config is not
readily available
require hacking up some way to generate that file before
you can configure
the pysaml2 client- would this new backend give a new way
to configure that
keying material? Ivan - Doesn't change the options for the
keying material.
But currently with xmlsec1 binary we invoke from the
command line and pass
in pointers to files. With new xmlsec module - won't have
to do that -
things are loaded from memory. But keys for satosa and
pysaml2 entities
need to be there. Trick: you can store those material as
base64 strings
within params - then entry point can unpack and store them
on docker file
system.
- Ivan has used another library to do signing parts - could
leverage this to clean up parts of the code.
- These can be optional choices - doesn't have to replace what is
already there
- There are some smaller things to looks into, and a few big ones
which need focus
- https://github.com/IdentityPython/pysaml2/pull/924 Configurable
options for the encryption algorithms
- Also some maintenance - taking care of date/time/locations -
deprecations in certain methods
- Need to merge a few things around how tests are run, pre-commit
configurations, etc.
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- pyeleven - important project - a release or maybe tag to make builds
more predictable. Pypi would be nice but not required.
- Victor was building a project around CA and parts of pyeleven - his
code should be under the SUNET repos.
- Should do a new release and make sure things are up to date - do
a check on the dependencies.
- pyff - issues -
- https://github.com/IdentityPython/pyFF/issues/265 - error when
trying to load certificates (which may not be well-formatted
- unclear).
This should be an easy fix.
- https://github.com/IdentityPython/pyFF/issues/264 - trickier
issue - taking the signature of metadata document when pyff uses
configuration with xrd file. Ivan is not familiar with using
it this way.
Need to understand why the check is being skipped. It worked properly
before but it not working correctly now. Did Matthew say he
was looking at
this? Out put of pyff is given to thiss.io
- SAMLtest test idp - gone - SATOSA image needs to be fixed.
https://github.com/IdentityPython/satosa-docker/issues/10
2 - AOB
- A topic for the board: There is a tension between delivering tools,
working on the proxy, and working on the services that support the proxy.
Need more people to be involved in the reviews. Issues are very complex, so
it is hard to find people to address things beyond the few that have the
overall knowledge.
