NameQualifier wrong in SAML Response

[Robert]

Example from a SAML Response:

<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://testsp2.aai.dfn.de/shibboleth" SPNameQualifier="h
ttps://testsp2.aai.dfn.de/shibboleth">3x51T1uQTYjBNVWkRoLPdzSkgCE=</saml2:NameID>

It seems in SamlProfileSamlNameIdBuilder#finalizeNameId the NameQualifier is not set correctly. If no explicit nameIdQualifier is set for a SAMLService, the NameQualifier has to be the entityId of the IdP or of the relying party.

In all of my testcases the NameQualifier was set to the issuer of the AuthnRequest, which is the SP.

Thats why the Shibboleth SP ignores the subject ID.

My quickfix would be the use the entityId of the IdP, but that will not handle relying IdPs. 

Is it a bug? Should I open a PR?

[Misagh]

> In all of my testcases the NameQualifier was set to the issuer of the AuthnRequest, which is the SP.
> Thats why the Shibboleth SP ignores the subject ID.

Judging by the spec, at least for "persistent" identifiers,

> In the case of an identifier with a Format of urn:oasis:names:tc:SAML:2.0:nameidformat:persistent, the NameQualifier attribute MUST contain the unique identifier of the identity provider that created the identifier.

So yes, this seems wrong.

> My quickfix would be the use the entityId of the IdP, but that will not handle relying IdPs.

Don't follow the last bit. What do you mean "relying IdPs"?

You'll need to account for entity ID overrides as well on per a SP
basis; may or may not be that quick.

> Is it a bug? Should I open a PR?

Sure.

[Robert]

Thanks for your fast answer. I will have a look, on how to fix it for persistent NameIdFormat.

My question was: What would be the correct unique identifier (entityId) in case of delegated authentication?

[Misagh]

No problem. If you look at `SamlProfileSamlAssertionBuilder`, you'll
find how to resolve the entity ID, in case the SP overrides for IDP
metadata. For delegation, the entity id is always that of CAS resolved
the same way, since CAS is the primary IDP to the SP anyway. The fact
that an external IDP was used to authenticate is not relevant in that
context.

[Robert]

Just fixed everything in my Overlay. Will open a PR tommorow.

I just found out, that releasing the eduPersonTargetedID as NameID Attribute is also not in  AbstractSamlObjectBuilder#newAttributeValue. I have added a quicktype checking for NameIDType and casting value to it, which produces a correctly released eduPersonTargetedID attribute (which is built dynamically via GroovyScript as complex object in our AttributeReleasePolicy).

<saml2:Attribute FriendlyName="eduPersonTargetedID" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

                <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.example.com/cas/idp" SPNameQualifier="https://sp.example.com/shibboleth">ESBrx6RqAIgLu46cUDIMzHf/5+Q=</saml2:NameID>

</saml2:Attribute>

I will attach this fix to, tho it is mandatory to exclude this attribute from consent policy, because XML Marshaller throws StackOverflowError, because of self "owner" Property of NameID which points to itsself.

Maybe you find a smarter way to attach NameID subject as attribute.

See https://wiki.geant.org/display/eduGAIN/IDP+Attribute+Profile+and+Recommended+Attributes#IDPAttributeProfileandRecommendedAttributes-HowtotestthereleaseoftherecommendedattributestotheExampleServiceProvider

[Misagh]

Sounds good. Thank you.