Attribute Resolver Migrating to IDP30 and generatin persistent NameId using PrincipalName
katia_muser at yahoo.com
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 n2.nabble.com>
To: Katia <katia_muser at yahoo.com>
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
>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 xsi:type="enc:SAML2StringNameID"
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.
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: http://shibboleth.1660669.n2.nabble.com/Attribute-Resolver-Migrating-to-IDP30-and-generatin-persistent-NameId-using-PrincipalName-tp7614884p7614885.html To unsubscribe from Attribute Resolver Migrating to IDP30 and generatin persistent NameId using PrincipalName, click here.
View this message in context: http://shibboleth.1660669.n2.nabble.com/Attribute-Resolver-Migrating-to-IDP30-and-generatin-persistent-NameId-using-PrincipalName-tp7614884p7614934.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users