No candidate NameID formats

[IAM David Bantz]

 I have encountered this problem and those log lines indicating that the
nameID generator does not trigger a nameID with that format from any of the
attributes released to that SP entityID.  (My IdP’s default nameID format
is transient rather than persistent, while yours appears to be persistent,
so I’ve seen those log messages when the SP required a different format.)
There are no doubt other and better approaches, but my solution has been:

   - determine what attribute will be the basis of the nameID for this SP
   - add or confirm attribute release policy for that SP entityID includes
   that source attribute
   - add or confirm nameID generator config will create nameID of the
   desired format from the chosen attribute for that SP entity ID
   (…conf/saml-nameid.xml)

Apologies if that doesn’t readily generalize to creating the requested
nameID-format=transient.




On Jan 2, 2023 at 09:45:01, Peter Schober via users <users at shibboleth.net>
wrote:

> I'm trying to override the NameID format to be used with an SP[1] but
> this fails and consequently no NameID element is added to the
> Assertion:
>
> 2023-01-02 18:00:31,477 - 127.0.0.1 - DEBUG
> [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:80]
> - Metadata specifies the following formats:
> [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]
> 2023-01-02 18:00:31,477 - 127.0.0.1 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:115]
> - Using overridden profile configuration ID:
> http://shibboleth.net/ns/profiles/saml2/sso/browser
> 2023-01-02 18:00:31,477 - 127.0.0.1 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:126]
> - Configuration specifies the following formats:
> [urn:oasis:names:tc:SAML:2.0:nameid-format:persistent]
> 2023-01-02 18:00:31,477 - 127.0.0.1 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:152]
> - Filtered non-metadata-supported formats from configured formats, leaving:
> []
> 2023-01-02 18:00:31,477 - 127.0.0.1 - DEBUG
> [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:318] - Profile
> Action AddNameIDToSubjects: No candidate NameID formats, nothing to do
>
> The former 3 log lines are clear and fully expected: Metadata for this
> SP lists (only) transient, configurtion (relyingparty override)
> specifies (only) persistent.
> The latter 2 log lines are not clear to me, however. I.e., why
> specifying the format in an override leaves the IDP with an empty set
> and "nothing to do"?
>
> This is from using only the aacli, there's no authn request involved.
> Any pointers?
>
> Best,
> -peter
>
> [1] This SP was redundantly registered by multiple Identity
> Federations but with slightly differing metadata. The copy our
> constituency consumed until recently contained NameIDFormat elements
> including "persistent" but now another copy is being used that only
> contains "transient". Short of getting that metadata amended by the
> changed upstream registrat the only way to make logins succeed to that
> SP would be to override the NameID format at every affected IDP.
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230103/e088dd2c/attachment.htm>