Default NameIDFormat Metadata Elements
Rod Widdowson
rdw at steadingsoftware.com
Thu Sep 15 06:34:07 EDT 2016
TLDR: rathole & hair splitting.
> There are at least two federations (I know of) that check for
> consistency between the protocolSupportEnumeration string and the
> endpoints (not the NameIDFormat).
Which way? I'd assume that an nnnService would require an associated protocol but not vice versa.
> In the above example, on the
> IDPSSODescriptor element, I would expect at least one SAML2 binding
> and one SAML1 binding. A SAML1 SingleSignOnService endpoint MUST be
> included to account for the "urn:mace:shibboleth:1.0" protocol string.
I don't see anything in the spec which supports your MUST:
> A whitespace-delimited set of URIs that identify the set of protocol
> specifications supported by the role element
supported != advertised
> On the AttributeAuthorityDescriptor shown above, I would expect a
> SAML1 AttributeService endpoint only. If there were a SAML2
> AttributeService endpoint but no SAML2 protocol string, the entity
> runs the risk of being filtered at the federation border.
Actually, AFAICS, the spec is stronger than that - it infers that any SAML2 support by the _ENTITY_ requires that in the
protocolSupportString, not limited to the RoleDescriptor element.
> For SAML V2.0 entities, this set MUST include the SAML protocol namespace URI,
> urn:oasis:names:tc:SAML:2.0:protocol
Note that it says entities, not Descriptor. That feels wrong, but I cannot find an errata so I cannot check. I'm hoping that Scott
will jump all over this and tell me why I'm wrong.
R
More information about the users
mailing list