Add NameIdFormat support to RelyingPartyRegistration

[Gayathri92]

RelyingPartyRegistration contains SAML 2.0 Metadata for both the relying party and its associated asserting party.

It would be nice to include NameIDFormat support in both RelyingPartyRegistration and RelyingPartyRegistration.AssertingPartyDetails. The application could then communicate a set of preferred formats to the asserting party (with #9297, for example) as well as lookup the asserting party's preferred formats.

[jzheaux]

Thanks for reaching out, @Gayathri92. Would you please add some more detail about your use case?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[amergey]

@jzheaux I saw your mention, I will try to submit a PR for this

[amergey]

We have some customers where specifying NameIdFormat is mandated by their IDP

NameIdFormat is a part of NameIDPolicy which support others attributes
According to SAML Core specification:

The <NameIDPolicy> element tailors the name identifier in the subjects of assertions resulting from an
<AuthnRequest>. Its NameIDPolicyType complex type defines the following attributes:

Format [Optional]
Specifies the URI reference corresponding to a name identifier format defined in this or another
specification (see Section 8.3 for examples). The additional value of
urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted is defined specifically for use
within this attribute to indicate a request that the resulting identifier be encrypted.

SPNameQualifier [Optional]
Optionally specifies that the assertion subject's identifier be returned (or created) in the namespace of
a service provider other than the requester, or in the namespace of an affiliation group of service
providers. See for example the definition of urn:oasis:names:tc:SAML:2.0:nameidformat:persistent in Section 8.3.7.

AllowCreate [Optional]
A Boolean value used to indicate whether the identity provider is allowed, in the course of fulfilling the
request, to create a new identifier to represent the principal. Defaults to "false". When "false", the
requester constrains the identity provider to only issue an assertion to it if an acceptable identifier for
the principal has already been established. Note that this does not prevent the identity provider from
creating such identifiers outside the context of this specific request (for example, in advance for a
large number of principals).

With some IDP, or the way it is configured, some Format value mandates the SPNameQualifier attributes to be set as well. (We saw that most of the time with PingFeredarate but with some others as well).

So in the PR instead of adding support for Format only, I also added support to configure the whole NameIDPolicy, in order to ease interop with some IDP use case

[jzheaux]

Good points, @amergey. I think I created some confusion by not first updating the description in this ticket. It's updated now.

The reason I'd like to leave changes to OpenSamlAuthenticationRequestFactory out of this PR is I'd like to see what happens with #9277 first since that may obviate the need to change the factory.

Would you be able to update the PR to match the issue's description?

[amergey]

@jzheaux Do you mean updating this PR by keeping only nameid format ? (so remove other part of nameid policy but keeping related work on metadata ?) . Also correct me if I am wrong but it seems to me NameID format is defined at SP level, there is no IDP metadatas related to NameID format.

[jzheaux]

Sorry for the delay, @amergey, I was on holiday.

Do you mean updating this PR by keeping only nameid format

Yes, since that's the only one that appears in metadata.

NameID format is defined at SP level, there is no IDP metadatas related to NameID format.

I was drawing my thoughts from line 658 of the spec in the SSODescriptorType section:

[Zero or More]
Zero or more elements of type anyURI that enumerate the name identifier formats supported by
this system entity acting in this role. See Section 8.3 of [SAMLCore] for some possible values for
this element.

which applies to both IDPSSODescriptor and SPSSODescriptor.

That said, I think it would be fine to only add it to the relying party for now. We can always add it to AssertingPartyDetails later if necessary.

[amergey]

NameID format is defined at SP level, there is no IDP metadatas related to NameID format.

I was drawing my thoughts from line 658 of the spec in the SSODescriptorType section:

[Zero or More]
Zero or more elements of type anyURI that enumerate the name identifier formats supported by
this system entity acting in this role. See Section 8.3 of [SAMLCore] for some possible values for
this element.

which applies to both IDPSSODescriptor and SPSSODescriptor.

That said, I think it would be fine to only add it to the relying party for now. We can always add it to AssertingPartyDetails later if necessary.

Sorry I was not clear enough, when I said "NameID format is defined at SP level, there is no IDP metadatas related to NameID format." I meant in OpenSAML implementation so it would be hard to support it on IDP anyway

[PHameete]

Hello all! Thank you for the discussion so far. I have an interest in this issue as well.

Currently if a Relying Party wishes to request the NameID in a specific format the suggested way in the docs is to modify the AuthnRequest as specified here https://docs.spring.io/spring-security/site/docs/current/reference/html5/#servlet-saml2login-opensaml-customization

It would be nice if the NameIDFormat field as present on the SPSSODescriptor field of the EntityDescriptor could be defined via the RelyingPartyRegistration. I think that would be more elegant than modifying a value 'last minute' in the AuthnRequest marshaller, and it would be present on the Relying Party metadata to allow for dynamic configuration as well.

I imagine this would be used as follows:

        RelyingPartyRegistrations
            .fromMetadataLocation(identityProvider.getMetadataUrl())
            .registrationId(identityProvider.getRegistrationId())
            .assertingPartyDetails(builder -> builder.setNameIdFormat(NameIDType.EMAIL))
            .build();

[fr2lancer]

Also it would be good to access it by

Saml2AuthenticationRequestContext.getRelyingPartyRegistration().getAssertingPartyDetails().**

[Bas83]

Unfortunately the link @PHameete shared seems to have been removed from the Spring docs, but an older version is up at https://docs.spring.io/spring-security/site/docs/5.5.2/reference/html5/#servlet-saml2login-opensaml-customization

[PHameete]

Thank you @jzheaux!