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.
*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
