*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.
*Idpy meeting 23 April 2024*
Attendees: Shayna, Ivan, Hannah
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Roland has an MR that has been approved.
- https://github.com/IdentityPython/idpy-oidc/pull/99
- Comes with some changes that break certain deployments (core AI
- but has been fixed)
- Move forward and then have new release of idpy-oidc
- There has been some focus on federations and supporting
capabilities of open id federations. Most of the work is in Roland's
personal repo for fedservice.
- https://github.com/rohe/fedservice - Roland is working in a wider
context around wallets, but everything binds together through the
federations.
- Ivan is working with Nicos L to import certain capabilites to
the front end that is being built for the Géant Core AAI platform.
Currently uses idpy-oidc and will now also use fedservice for
federation
capabilities.
- There are a few items that need to be revisited: client
notification methods - private keyjwt and how it is handled internally in
the library; how to keep public keys from the metadata, how to
refresh, how
often - Ivan needs to discuss with Roland - these capabilities
are needed.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Ivan is now getting back to this project. There are outstanding items
pending:
- merged an MR on master that introduces exception cases that have
wrong variable names - error handler is then crashing. Fixes
need to be
done to address this.
- Roland's open PR to fix the dependencies and how they are
checked - https://github.com/IdentityPython/SATOSA/pull/442 -
missing checks of whether idpy-oidc and other libraries are
in dependencies
- Ivan needs to fix these parts and merge, then have a new release
- There is pending work around routing workaround paths -
https://github.com/IdentityPython/SATOSA/pull/451 - instead of
running at example.com, you could have SATOSA running at
example.com/satosa. This is useful not only for deployments that
need it but also for separating out what the paths mean. Then
there can be
separate controllers and handlers for different paths. Looking into
changing the framework. PR needs some work - Kristof B is
aware. There was
a previous PR that was more complex, so this one was created
to specify the
problem in a clearer way and move forward.
- Ali and Hannah's work with the logout is very important.
- https://github.com/IdentityPython/SATOSA/pull/444 - logout from
idp side
- https://github.com/IdentityPython/SATOSA/pull/431 - logout
from service side and propagates to other entities.
- important to decide how to organize keeping state on the
server side. The cookie can not hold any more information.
- Some other issues: How to handle claims for oidc -
https://github.com/IdentityPython/SATOSA/issues/457 - mapping of
what the standard oidc claims should be - including
multi-valued which can
be represented as an array, a space separated string, etc.
What about a
non-standard claim? Certain profiles for EduPerson for example. Map an
internal claim - single value as a string, not a list. There will be
discussion on this. Main idea is to extend internal attributes mapping
file, making a more complex structure which indicates how
these values can
be compared to other values, how many items to exist, what types they
should be, etc.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- https://github.com/IdentityPython/pysaml2/pull/924
- Main concern - what to do with XMLsec1. Should there be a move to a
different way of encrypting/decrypting/signing/verifying SAML payloads?
- With which algorithms should the payload be signed or encrypted?
Which algorithms do we accept as valid for signatures to
allow decryption?
- Ivan plans to focus on this soon.
- Ivan knows people are waiting on some answers on other issues
and he is trying to get them.
- Ongoing issue: Python and its support for temporary files on the
Windows platform- Ivan has a small patch locally. Another user has a
proposed solution for checking temporary files and deleting
afterward. but
it is not a long-term solution. Ivan would prefer it to be automatic if
possible. Ivan's patch is a workaround. He will post it, but this needs
further discussion. With Linux WSL the temporary file deletion
just works,
but Windows breaks. Few users are affected, but it does come up.
- https://github.com/IdentityPython/pysaml2/pull/951 - bug fix for
domain validation - in practice everyone sets properties in the SAML
response that specify where the response came from as an IP address. This
only affects domain names. User has suggested a fix but it includes the
port. Strictly, the port is not part of the domain. Ivan has made
suggestions on the PR.
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- There is a new release of the pyMDOC-CBOR library.
- There was a change to support more algorithms used to serialize
payload.
- https://github.com/IdentityPython/pyMDOC-CBOR/pull/6
2 - AOB
- Next meeting May 14 due to Greek holidays.
Dear colleagues,
The InCommon Technical Advisory Committee wants your help bringing a “good
practice” approach to research and education (R&E) identity federation.
Would you please join me on Tuesday, May 7, at 1:00 PM UTC, to plan how we
might accomplish this? We will rough out a regular meeting schedule and
set some immediate goals for the Federation Readiness Check working group
then. (See below/attached for meeting details.)
A significant roadblock for new R&E community members is validating their
identity provider (IdP) or service provider (SP) deployments. Current good
federation practice involves an overwhelming variety of expectations,
standards, entity categories, frameworks, profiles, and more. There exists
no single, comprehensive resource for operational guidance and integration
testing. What documentation or test resources exist are difficult to find
even for experienced IAM professionals, are typically restricted to
federation members, and are focused almost exclusively on IdPs. While the
decentralized nature of R&E federation allows it to scale far beyond
current commercial offerings, that same decentralization makes enacting
meaningful change to IdP, SP, or federation operations seemingly
impossible. A scorecard would be a powerful tool for change.
Federation Readiness Check Working Group membership is open to the public.
Please feel free to forward this invitation to anyone you think would be
interested. Our initial meeting will be held on Tuesday, May 7, 2024, at
1:00 PM UTC via Zoom (
https://researchdata-us.zoom.us/j/81548511164?pwd=Uzh3UTXMdmldUWMK3pPWd85mr…)
We will continue the discussion on the fedtestwg mailing list (
https://lists.incommon.org/sympa/info/fedtestwg) and the
#inc-fed-ready-check-wg Slack channel (https://internet2.slack.com/)
Working group materials will be posted to the Internet2 Confluence wiki (
https://spaces.at.internet2.edu/display/inctac/federation-readiness-check-wg
).
Please note that as an Internet2 Activity, the Internet2 Intellectual
Property Policy applies the working group (
https://internet2.edu/community/about-us/policies/internet2-intellectual-pr…)
Please direct any Internet2 policy questions to legal(a)internet2.edu.
Best wishes,
Matthew
--
Matthew X. Economou, Vice President of Engineering
Research Data and Communication Technologies
P.O. Box 81 Garrett Park, MD 20896 USA
Office: +1 (301) 760-7383 x813
Mobile: +1 (513) 445-2323
Email: meconomou(a)researchdata.us
Hello,
I have two questions, if you don't mind:
1. I have a *LogoutResponse* via redirect (HTTP GET) as follows:
*/logout?SAMLResponse=...&Signature=...&SigAlg=...
*. This type of message originates from EntraID (formerly Azure).
This *SAMLResponse* does not internally contain a signature. How can I
check the signature since *parse_logout_request_response* doesn't accept
SigAlg and Signature parameters, unlike *parse_logout_request*?
2. Secondly, if my *LogoutResponse* is like */logout?SAMLResponse* (without
SigAlg or Signature parameters), how can I be sure that it contains a valid
signature? Can I rely on *want_assertions_or_response_signed*, which is
used in *AuthnResponse*, but not in *LogoutResponse(StatusResponse)*?
Thank you,
Hello idpy contributors!
Roland and I are stepping down from the idpy board, and four other seats are up for election with board members interested in continuing. This leaves us with five seats up for election for the 2024-2026 term.
We have several individuals interested in joining the board and are looking for your feedback.
Incumbent nominees:
• Ivan Kanakarakis (SUNET, lead architect for Satosa, pySAML)
• Chris Whalen (individual contributor)
• Mike Jones (OIDF, author of OIDC and JWT and OAuth)
New nominees:
• Fresia Pérez Arriagada (SUNET)
• Jakob Schlyter (Kirei)
• Warren Anderson (LIGO)
Leif Johansson (SUNET) and Christos Kanellopoulos (GÉANT) are in the middle of their 2023-2025 terms; those seats are up for election next year.
Please go to the following Zoom survey link by 18 March 2024 to place your votes for five (5) board members.
Thanks! Heather
