Extending the SP Dynamic Metadata Provider

[Tom Scavo]

On Sat, Oct 28, 2017 at 12:00 PM, Rod Widdowson
<rdw at steadingsoftware.com> wrote:
>> In any case, can you explain why artifacts are a nightmare?
>
> In the case when MDQ is being used (and although this is a majority of deployments it is a minority of configurations):
>
>         - In the SAML1 case the artifact may not be carrying the SHA1 of the entityID
>         - In the SAML2 case the use of the SHA1 as the name is only the convention, not the requirement

Actually for SAML1 it's a little better than that [1]:

<quote>
SAML V1.x identity providers that do not use the SHA-1 hash of their
entityID as their SourceID MUST include a <saml1md:SourceID> element
containing the hex-encoded value of their 20-byte SourceID in the
<Extensions> element of their <md:IDPSSODescriptor>.
</quote>

AFAIK there are no <saml1md:SourceID> elements in published metadata,
which means all SAML1 IdP deployments are using the SHA-1 hash of
their entityID or there is no appreciable usage of SAML1 artifacts.
The same can probably be said of SAML2 artifacts.

I don't know if the SP supports the <saml1md:SourceID> element in
metadata, and I'm not suggesting it should, but the point is that
artifact resolution is a problem in any case, not just in the presence
of MDQ.

Tom

[1] Metadata Profile for the OASIS Security Assertion Markup Language
(SAML) V1.x http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml1x-metadata-os.pdf