Shibboleth Identity Provider Security Advisory [13 May 2026]

[Peter Schober]

Bernd Oberknapp <bo at ub.uni-freiburg.de> [2026-05-14 01:42 CEST]:
> With an jdk.xml.elementAttributeLimit of 30 our IdP fails to load the
> eduGAIN metadata, which has about 60 attributes in the EntitiesDescriptor
> element.

ACK, I just iterated through values and found that using 60 it would
load our locally-produced metadata including the eduGAIN aggregate-

Scott Cantor via users <users at shibboleth.net> [2026-05-14 02:59 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.
One thing I noticed in the past (and this may in fact be a pyff issue,
too) is that XML namespace declarations are not normalised (not using
one consistent prefix for one formal namespace URI) but instead any
prefix used by any of the source metadata documents is preserved and
added to the final document, leading to something like this on the
root element:
<md:EntitiesDescriptor
  xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:ns0="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:q1="urn:oasis:names:tc:SAML:2.0:metadata"
  etc.pp.

Currently there are 54 unique xml nsdecls in our own aggregate even
though we're only declaring (and using) 13 of those ourselfs.

> 2. Nobody should be consuming that metadata, let alone any aggregate in 2026.

No SAML IDP or SP operator should of course be consuming the eduGAIN
MDS aggregate (for several reasons, including there being no sane way
of ever coordiating key rollovers with potentially thousands of
unknown metadata consumers) but *all* of the currently 84 federations
currently participating in eduGAIN (https://technical.edugain.org/) do
have to consume and process and republish that document to their
constituency in one form or another (including not in aggregate form).

We can certainly disagree about of the severity of the problem of
aggregates (resource consumption, mostly, with sideeffects for
implementations such as the Shib SP via its legacy XML parser) vs. the
severity of the problem of avoiding aggregates (introducing hard
realtime-dependencies on central federation infrastructure, only
partially mitigated by optional end entities' caching efforts;
decentral IDP discovery).  But I'm guessing we're not the only ones
still using (and having our constituency consume) aggregates. And at
least I "didn't get the memo" that the (eduGAIN) metadata we're all
necessarily relying on was in such a bad state it would warrant an
urgent fix.

(FWIW, I don't have specific numbers but with the current size of the
eduGAIN MDS aggregate being 88MB I doubt this has been growing at a
significant rate in recent times or that it will grow significantly in
the near future.)

> 3. Regardless of 1 and 2, we know that metadata is borked, and
> that's precisely why we didn't default things that way and split off
> the metadata parsing bean so it would ue a different default, and
> set up separate properties to control it independently.

Thanks for your efforts in this regard.

I'm a bit behind with my communication and documentation efforts to
push our constituency towards IDP 5.2+, mostly due to the changes
inflicted by the need for Servlet 6.1 (and from that, for Tomcat 11
and from that for Debian 13, at least if you wanted automated, easily
appliable security updates for the OS, Java and the Java servlet
container).

Going forward I'll have to consider rebuilding our recommended
deployment based on the new Jetty plugin, though that still leaves it
up to deployers to let themselfs be notified about any issues in Jetty
(and then have the Shibboleth devs shib an updated version in form of
the plugin) -- which I know is not something (m)any are doing.
(Which is why our current local docs and deployment instructions are
still specific to Debian + OpenJDK + Tomcat: The only FLOSS stack I
know of where you reliably get security fixes for all of the
components minus the Shibboleth IDP software itself.)

Best,
-peter