Attribute Resolver Migrating to IDP30 and generatin persistent NameId using PrincipalName

Katia katia_muser at
Tue May 12 10:08:42 EDT 2015

Thanks for the quick answer.
1 .I did not provide the salt from my configuration file so no compromise here :) I shoudl have used 123456 to make it more clear2.  The username is indeed a numerical value3. I did uncomment the shibboleth.SAML2PersistentGenerator bean in saml-nameid.xml4. in my attribute-filter.xml file I've included the following<afp:AttributeFilterPolicy>        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="<provider SP>" />
        <afp:AttributeRule attributeID="persistentNameIdSourceUid">            <afp:PermitValueRule xsi:type="basic:ANY" />        </afp:AttributeRule>      </afp:AttributeFilterPolicy>
In the consent screen I do this this attribute listed as being released:------------------------------You are about to access the service:xxxxx.comInformation to be Provided to ServicepersistentNameIdSourceUid   123456789---------------------------------
Thanks for your insights!
Katia   From: "Cantor, Scott E. [via Shibboleth]" <ml-node+s1660669n7614885h30 at>
 To: Katia <katia_muser at> 
 Sent: Monday, May 11, 2015 9:29 PM
 Subject: Re: Attribute Resolver Migrating to IDP30 and generatin persistent NameId using PrincipalName
 On 5/12/15, 1:07 AM, "Katia" <[hidden email]> wrote:

>I've went through the post from 2 weeks ago from Sara (IdPv3 and 
>persistent NameID) and the subsequent responses and I followed the steps
>detailed in the documentation to support PersistentId NameId
>Content of
>idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator
>idp.persistentId.sourceAttribute = persistentNameIdSourceUid
>idp.persistentId.salt = XXXXXXX
If that's the real salt, you've just compromised the opacity of all those 
IDs. That's like divulging a private key.

>However my attribute_resolver configuration that worked in V2 is now 
>   <resolver:AttributeDefinition id="persistentNameIdSourceUid"
>          <resolver:AttributeEncoder
>nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
>          <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
>nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
>      </resolver:AttributeDefinition>
That's putting the user's principal name into a SAML NameID with a format 
specifically designed for use with opaque pairwise IDs in the SAMl 2 case, 
and the transient format in the case of SAML 1. That's not correct. It 
"works", but it's wrong. Those encoders should not be there, or at the 
least they should have different formats.

Also, it's a bad idea to generate persistent IDs using a username as a 
seed, unless that username is opaque/numeric/whatever. Otherwise it's not 

>In IDP30 I get this error using the same provider 
>WARN [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:337] -
>Profile Action AddNameIDToSubjects: Request specified use of an
>unsupportable identifier format:
>Let me know if you need more details.

I guess, yes. My best guess is maybe the persistentNameIdSourceUid 
attribute is not being released.

You also might not have uncommented the 
shibboleth.SAML2PersistentGenerator bean in
saml-nameid.xml, which the documentation includes as a step. Though given 
the rest of that, I think if the attribute were released it would be 
working because of the legacy use of the resolver and the 
SAML2StringNameID encoder, and you'd get a persistent NameID with the 
username in it.

-- Scott

To unsubscribe from this list send an email to [hidden email]
   If you reply to this email, your message will be added to the discussion below:   To unsubscribe from Attribute Resolver Migrating to IDP30 and generatin persistent NameId using PrincipalName, click here.

View this message in context:
Sent from the Shibboleth - Users mailing list archive at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list