AM 6.0 persistent nameid-format issue

Tagged: ,

This topic has 5 replies, 5 voices, and was last updated 4 weeks ago by Scott Heger.

  • Author
  • #27840
     Kabi Patt

    Problem Statement:-
    Getting a “HTTP Status 500 ” or “InvalidNameIDPolicy” error for a remote SP that support persistent name-id format

    Here is the Set up :-
    I have a SP that supports persistent name-id format. My AM6.0 IDP’s “NameID Value Map” has the entry :- urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=uid

    And the SP’s “NameID Format List” has the entry :- urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

    Now the Result :-
    My SP-initiated call after successful authentication is ending in a “HTTP-500 error- Unable to do Single Sign On or Federation” . The debug file shows the following errors :

    ERROR: UtilProxySAMLAuthenticator.generateAssertionResponseUnable to do sso or federation.
    com.sun.identity.saml2.common.SAML2Exception: Service provider does not support name identifier format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.
    at com.sun.identity.saml2.common.SAML2Utils.__AW_verifyNameIDFormat(
    at com.sun.identity.saml2.common.SAML2Utils.verifyNameIDFormat(

    To resolve this, I added “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent” to SP’s “NameID Format List”. That resolved the “HTTP-500″ error, but resulted in a new error. The SAML response after authentication shows
    samlp:StatusCode xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”
    Unable to generate NameID value because NameID persistence has been disabled.

    Any of you know the fix ?



    Is your SP configured with SAML:1.1? I suggest trying with SAML 2.0.


    Just clarifying the above, make sure urn:oasis:names:tc:SAML:2.0:nameid-format:persistent is supported in your SP metadata. And since you plan to use persistent format, ensure Disable NameID Persistence is not checked.

    Hope this helps!


    Thank you Jatinder,
    yes, Disable NameID Persistence is not checked in my configuration

    Do you mean to change
    urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified ?

    Sorry, I had a typo in my orginal question.
    “…I added “urn:oasis:names:tc:SAML:2.0:nameid-format:persistent” .
    The correct sentence is
    “…I added “urn:oasis:names:tc:SAML:1.1:nameid-format:persistent”

     Dale Thompson

    Hi Kabi, did you get this issue resolved?

     Scott Heger

    Without a SAML trace this is a guess as to what is going on in the initial scenario:

    The SP is not sending urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified as the requested nameid format in its AuthnRequest and the IDP is choosing to create the nameid with whatever format is at the top of its list of supported nameid formats. If this is what is going on then either get the SP to send urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified as the requested format and also ensure that urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified is listed in the IDP as a supported nameid. Or if you can’t get the SP to request it then put urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified as the top or only supported nameid format in your IDP.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

©2020 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?