persistent-id as an attribute

James Oulman oulman at ufl.edu
Mon Nov 5 13:08:32 EST 2018


Good afternoon,

We have a project underway to upgrade to IdP 3.4, and in trying to 
convert our NameID configuration from attribute-resolver to saml-nameid, 
we have run into an issue. For reasons that predate me we vend 
eduPersonTargetedId as an attribute via the following configuration.

     <resolver:AttributeDefinition id="eduPersonTargetedID" 
xsi:type="SAML2NameID" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" 
sourceAttributeID="storedID">
         <resolver:Dependency ref="storedID_dc" />

         <resolver:AttributeEncoder xsi:type="SAML1XMLObject" 
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                 name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />

         <resolver:AttributeEncoder xsi:type="SAML2XMLObject" 
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" 
friendlyName="eduPersonTargetedID" />

      </resolver:AttributeDefinition>

It looks like this is deprecated and will be removed in V4 and was never 
really a recommended approach. We have enough SPs for whom we are 
vending this attribute that there is concern about just removing it. 
Acknowledging that this is not recommended, is there any way to 
reproduce this as an attribute using modern syntax? Or is our only 
option to test SP-by-SP and implement a persistent subject NameID for 
the ones who break?

Thank you.

-James


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3980 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20181105/5789dbaf/attachment.p7s>


More information about the users mailing list