An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Brand <peter.brand AT univie.ac.at>]

Daniel,

I may not be understanding your question correctly in the specific
context of your use of the Shibboleth IDP software as a SAML proxy so
I'll answer the question as if it were immaterial whether your Shib
IDP externalised its authentication to another IDP (MS Azure).

Daniel Muscat <daniel.muscat AT um.edu.mt> [2024-04-25 20:13 CEST]:
> I need a system that can manage the list of Service Providers
> allowed for authentication and enable me to modify the attributes to
> send. Could you please suggest what you usually recommend to your
> clients or use yourself?

FWIW, the only way our IDPs limit what Service Providers they accept
authentication requests from is via SAML Metadata (or comparable local
configuration[1]).  Almost all of our IDPs interfederate via eduGAIN
which means they're "limiting authentication" to several thousand SPs
-- which is not very "limited" but goes to show that IMO this is not
something you should worry about (beyond metadata management).

What attributes to send to what SPs is a completely different matter.
You might find our own local documentation helpful:
https://wiki.univie.ac.at/display/federation/IDP+5+Attribute+release

> There are several approaches to enabling controlled release of
> attributes to the appropriate services and most (or all) of them will
> probably need to be deployed within an institutional IDP

To get *controlled* and *scalable* attribute release you may want to
release attributes based on:

* entity categories / entity attributes
* the registrar of the metadata (you may trust yourself more than others)
* the comparably "innocuous" nature of some attributes
  (e.g. release eduPersonScopedAffiliation, schacHomeOrg and maybe an
  opaque identifier to anyone known via metadata)
* consent provided by the subject (maybe only as a last resort)

HTH,
-peter

[1] Such as OIDC client resolvers.