[EXTERNAL] Re: saml proxying scoped attributes...best practice

[Bobby Lawrence]

Correct me if I’m wrong, but the MQD aggregate of IdP-only metadata is effectively the same as the legacy variant…the result is a rather large XML file to load.

https://mdq.incommon.org/entities/idps/all
vs
http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml

From: Alan Buxey <alan.buxey at myunidays.com>
Sent: Wednesday, November 13, 2024 9:42 AM
To: Shib Users <users at shibboleth.net>
Cc: Cantor, Scott <cantor.2 at osu.edu>; Bobby Lawrence <robertl at jlab.org>
Subject: [EXTERNAL] Re: saml proxying scoped attributes...best practice

hi,

The MDQ is great for IdPs to fetch metadata for SPs on the fly, but the reverse isn't ideal.  SPs need to know all IdP metadata up front in order to provide discovery and the MDQ doesn't really work for that.  The result is that if an SP is to accept logins from any federated IdP, it needs to load a large metadata file.  Luckily InCommon (and maybe others) provide an IdP-only variant, but its still huge.

An SP needing to preconfigure or offer discovery , based on metadata, can use the metadata (and InCommon provide an MDQ 'feed' of all the IdPs - which is also much much faster to get than the old legacy metadata file (!) ) - whilst also allowing their SP to use the MDQ feed itself - to massively improve startup/restart times but also memory usage.   you then have the best of both worlds - as the service will only offer IdPs that are known/configured and the SP SAML stack will be more performant and happily deal with those IdPs when started with eg the SP initiated flow, as it's got them via its MDQ config.

alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20241113/6877ff47/attachment.htm>