Peter Schober peter.schober at
Fri Feb 23 04:13:07 EST 2018

* ofaklintrafo <ofa at> [2018-02-23 09:37]:
> I am trying to understand where I need to adjust the configuration on the IDP
> and SP to release a nameid persistent identifier to a service provider.
> The attribute resolver configuration file has a definition of an uid
> attribute
> <AttributeDefinition xsi:type="Simple" id="uid" sourceAttributeID="uid">
>         <Dependency ref="mySIS" />
>         <AttributeEncoder xsi:type="SAML2String"
> name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid"
> encodeType="false" />
> </AttributeDefinition>
> I would like to release a persistent identifier to a service
> provider SP1 which is stable with respect to SP1, based on the value
> of the uid attribute but hashed for privacy reaons.

1. Persistent NameIDs are something very specific. Unless you're sure
you need them I'd go for a more literal implementation of what you're
after, and send it as attribue. The obvious alternative/replacement is
the new SAML SubjectID (or pairwiseID, if you must), which can be
created and released as an attribute:

2. Are you sure uid is suitable? Persistent NameIDs as well as the
SubjectID attribute profile-defined attributes prohibit re-assigning
of values, so if one person with a uid could quit and (possibly much)
later someone else comes along and gets assigned the same uid (maybe
the have the same name or whatever) that would violate the spec.

> From documentation I think that this is the case described on this page: 
> So I have uncommented and adjusted the following lines in
> and also the SAML2PersistentGenerator in the
> saml-nameid.xml
> idp.persistentId.sourceAttribut = uid 
> idp.persistentId.useUnfilteredAttributes = true
> idp.persistentId.algorithm = SHA
> idp.persistentId.salt = changethistosomethingrandom
> idp.persistentId.encoding = BASE32
> But which attribute should I release to the service provider ?

You don't have to change any of the defaults here except
sourceAttribute (note that your property is missing the final "e"
above, however that happened!) and the salt. Leave all other defaults.
(useUnfilteredAttributes is unrelated to persistent NameIDs, AFAIR.)

The only other thing to do is uncommenting the
  <ref bean="shibboleth.SAML2PersistentGenerator" />
line in conf/saml-nameid.xml, i.e., removing the comments above and
below that line, and restarting the IDP. Then your IDP has persistent
NameIDs available.

When and to whom to release those is governed by the SP's metadata
(have it list persistent as first NameIDFormat in its metadata) or the
SP requesting a specific format in its authentication request
(unlikely, to happen, since not all IDPs support that, no SP can
safely request it) or your relying party config overruling it.

So if you manage the SP's metadata locally just add this line
to its metadata, after any SingleLogoutService elements but before the
first AssertionConsumerService element.

Reload the metadata provider this entity is provided by
(./bin/ and test with the aacli tool:

$ ./bin/ --saml2 -n SOMEUSER -r SOME-SPs-ENTITY-ID

> Currently I have the attributes for the SP1 service provider defined
> in the attribute-filter.xml.

Ignore the filter for persistent NameIDs when configured as above.
The above is all you need /if/ you wanted to use persistent NameIDs.
Scott will say you shouldn't. ;)


More information about the users mailing list