<html><body><div dir="ltr">
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:</div><div dir="ltr"><ul dir="ltr" style="margin:0px;list-style-type:"\002013 ""><li>determine what attribute will be the basis of the nameID for this SP</li><li>add or confirm attribute release policy for that SP entityID includes that source attribute</li><li>add or confirm nameID generator config will create nameID of the desired format from the chosen attribute for that SP entity ID <br>(…conf/saml-nameid.xml)</li></ul><div dir="ltr">Apologies if that doesn’t readily generalize to creating the requested nameID-format=transient.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div><br></div></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Jan 2, 2023 at 09:45:01, Peter Schober via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div>
<div>
I'm trying to override the NameID format to be used with an SP[1] but<br>this fails and consequently no NameID element is added to the<br>Assertion:<br><br>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]<br>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: <a href="http://shibboleth.net/ns/profiles/saml2/sso/browser">http://shibboleth.net/ns/profiles/saml2/sso/browser</a><br>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]<br>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: []<br>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<br><br>The former 3 log lines are clear and fully expected: Metadata for this<br>SP lists (only) transient, configurtion (relyingparty override)<br>specifies (only) persistent.<br>The latter 2 log lines are not clear to me, however. I.e., why<br>specifying the format in an override leaves the IDP with an empty set<br>and "nothing to do"?<br><br>This is from using only the aacli, there's no authn request involved.<br>Any pointers?<br><br>Best,<br>-peter<br><br>[1] This SP was redundantly registered by multiple Identity<br>Federations but with slightly differing metadata. The copy our<br>constituency consumed until recently contained NameIDFormat elements<br>including "persistent" but now another copy is being used that only<br>contains "transient". Short of getting that metadata amended by the<br>changed upstream registrat the only way to make logins succeed to that<br>SP would be to override the NameID format at every affected IDP.<br>-- <br>For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div>
</div>
</blockquote>
</div></body></html>