AW: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

philip.nemeth at philip.nemeth at
Sat Jan 9 19:43:50 UTC 2021

Hello Nate,

first of all – thank you very much for your answer!
Our Application use urn:oasis:names:tc:SAML:2.0:nameid-format:persistent and i think you are right, the IDP cant handle it.

I think you are right, the saml-nameid.xml ist not correct oft that.

With IDP2 our Configuration was this:

  <resolver:AttributeEncoder xsi:type="SAML1String"
    name="urn:mace:dir:attribute-def:userPrincipalName" />

  <resolver:AttributeEncoder xsi:type="SAML2String"
    friendlyName="userPrincipalName" />

  <!-- for including the persistent NameID in the response -->

    nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />

  <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
    nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
But i think, i must „translate“ the code in saml-nameid.xml?

Greetings from Vienna,

Von: Nate Klingenstein-5 [via Shibboleth] <ml+s1660669n7648280h95 at>
Gesendet: Samstag, 9. Jänner 2021 19:03
An: philip.nemeth at
Betreff: RE: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?


Odds are that you haven't configured your IdP to be able to send persistent nameID's:

> 2021-01-09 15:23:47,561 - - WARN [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:334] - Profile Action AddNameIDToSubjects: Request specified use of an unsupportable identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

As indicated by your snippet of saml-nameid.xml.

>         <!-- Uncommenting this bean requires configuration in -->
>         <!--
>                      <ref bean="shibboleth.SAML2PersistentGenerator" />
>         -->

As such, the IdP is unable to generate the requested NameID format and meet the policy requirements of the SP with which it's attempting to communicate, causing it to error out.  You'll need to follow the appropriate steps to enable the generation of persistent NameID's.  It's a slightly tricky topic, so be sure to follow the documentation closely.

If the service actually requires persistent NameID's, then you'll need to go through full configuration and understanding of them.  If it doesn't and it's misusing the standard(which is fairly common in deployment), then you can put a hack in place(ill-advised in most cases), or reconfigure the service's metadata/AuthnRequest to require a different NameID format.

Best wishes,

Signet, Inc.
The Art of Access ®

For Consortium Member technical support, see
To unsubscribe from this list send an email to [hidden email]</user/SendEmail.jtp?type=node&node=7648280&i=0>

If you reply to this email, your message will be added to the discussion below:
To unsubscribe from Shibboleth - Users, click here<>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list