Shibboleth Identity Provider Security Advisory [13 May 2026]

[Peter Schober]

Scott Cantor <scott at restingparrotsoftware.com> [2026-05-14 16:48 CEST]:
> >> 1. That mnetadata is not formed sensibly.
> > 
> > If there are concrete errors or mistakes I'd be happy to report them
> > to the eduGAIN Operations Team.
> 
> 25 declarations of a single namespace with different prefixes is
> about as clear a definition of "not sensible" as I can think
> of.

ACK.

FTR, just because I looked it up myself, here are the namespace
prefixes declared more than once within the eduGAIN aggregate, so what
should be 11 declarations end up being 30:

      4 "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
      4 "urn:oasis:names:tc:SAML:2.0:metadata"
      4 "urn:oasis:names:tc:SAML:2.0:assertion"
      3 "urn:oasis:names:tc:SAML:metadata:algsupport"
      3 "http://www.w3.org/2000/09/xmldsig#"
      2 "urn:oasis:names:tc:SAML:profiles:SSO:request-init"
      2 "urn:oasis:names:tc:SAML:metadata:ui"
      2 "urn:oasis:names:tc:SAML:metadata:attribute"
      2 "urn:mace:shibboleth:metadata:1.0"
      2 "http://www.w3.org/2001/XMLSchema"
      2 "http://refeds.org/metadata"

Add to that the list of 24 either consistently prefixed or
private/non-standard one-offs:

      1 "urn:oasis:names:tc:SAML:protocol:ext:req-attr"
      1 "urn:oasis:names:tc:SAML:metadata:rpi"
      1 "urn:oasis:names:tc:SAML:2.0:protocol"
      1 "urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"
      1 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      1 "http://www.w3.org/2005/08/addressing"
      1 "http://www.w3.org/2001/XMLSchema-instance"
      1 "http://www.w3.org/2001/XInclude"
      1 "http://www.w3.org/2001/04/xmlenc#"
      1 "http://www.eenet.ee/EENet/urn"
      1 "http://wayf.dk/2014/08/wayf"
      1 "http://ukfederation.org.uk/2006/11/label"
      1 "https://seamlessaccess.org/NS/trustinfo"
      1 "https://federation.renater.fr/metadata"
      1 "http://schemas.eduserv.org.uk/openathens-federation/1.0"
      1 "http://pyff.io/NS"
      1 "http://eidas.europa.eu/saml-extensions"
      1 "http://eidas.europa.eu/metadata/servicelist"
      1 "http://eduserv.org.uk/labels"
      1 "http://eduid.cz/schema/metadata/1.0"
      1 "http://docs.oasis-open.org/wsfed/privacy/200706"
      1 "http://docs.oasis-open.org/wsfed/federation/200706"
      1 "http://docs.oasis-open.org/wsfed/authorization/200706"
      1 "http://docs.oasis-open.org/ns/xri/xrd-1.0"

Those may not be as easily avoidable as the redundantly declared ones.

> That leads directly to the point that it's not meant for public
> consumption, it's a system artifact of a service designed to be used
> by the federations. If they're happy with it, fine. But by exposing
> it to clients, I think they kind of have an obligation to do things
> sensibly or tell people that they don't intend to cater to that use
> case.

I think there probably were (are?) a few offenders among the eduGAIN
participant federations who did not understand that it's plain wrong
to point their members to the eduGAIN MDS ("trust is always local", as
leifj often said, here meaning: there's no reason any IDP or SP
deployer should trust the eduGAIN MDS metadata or signing key).
If this were up to me I'd long have restricted access to that resource
to only the participant federations who need to process it.
Doing that now doesn't of course address the issue.

> Right, but that's not this aggregate; we assume part of the point is
> to clean it all up, and the federations we work the most closely
> with do that, using our software a lot of the time. It helps clean
> up these issues.

Point taken. I'll raise an issue with pyFF (not sure about its
maintenance state these days) but it seems I may also have to look at
replacing pyFF with the Shibboleth MDA on short notice, if that'll
take care of the underlying issue for our local constituency.

> People can't have it both ways. I realize it's partly that we hear
> the loudest voices, and the ones who aren't on board with all those
> changes aren't as loud about it. I guess I would make the case that
> people need to speak up if they disagree with what's coming.

I have whiplash from shaking my head in bewilderment at how that whole
OpenID Federation stuff is supposed to work (after having participated
in a whole-day workshop at the recent https://tiime-unconference.eu/)
and at how many things are still left for deployers to figure out.
And that's not even taking into account the perennial "migration"
phase we're entering (or forcing our communities into, really).

Best,
-peter