saml proxying scoped attributes...best practice

[Alan Buxey]

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/851d72c2/attachment.htm>