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