ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

[Sheldon, Nathan I]

Thanks Scott and Peter for the quick reply.

I’ll switch to using the InputDataConnector within the DataConnector definition then.

Appreciate the help.

----
Nathan Sheldon
Systems Integration Engineer
    Identity and Access Management,
    Information Technology Services
University of California, San Francisco






On Feb 3, 2020, at 11:37 AM, Peter Schober <peter.schober at univie.ac.at<mailto:peter.schober at univie.ac.at>> wrote:

* Sheldon, Nathan I <Nathan.Sheldon at ucsf.edu<mailto:Nathan.Sheldon at ucsf.edu>> [2020-02-03 20:25]:
The documentation for the ComputedIdConnector at
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_display_IDP30_ComputedIdConnector&d=DwIGaQ&c=iORugZls2LlYyCAZRB3XLg&r=nu8TjafRyATXiCWMkFtf5v6w2YFX7dlXPahFfE1PUk0&m=09AFWFqqwbyZsMojOI-ub44juIcC4aWVMBuSWX69ik8&s=5Z6m1P4vSoHwwwxjNwLCzotH7Tx0BW7fDrvVsEsW1R8&e=
indicates that, as of version 3.4, the sourceAttriubteID data
connector attribute has been deprecated.

You can remove the sourceAttriubteID XML attribute from your
DataConnetor.

Personally I've added a child attribute to the DataConnector:
 <InputDataConnector ref="myLDAP" attributeNames="%{idp.persistentId.sourceAttribute}" />
that re-uses the same source attribute config I did for supporting
persistent NameIDs NOT wrapped in a SAML attribute but if you're not
using those you can avoid the indirection/property and put the
internal identifier's attribute name into "attributeNames" above.

The saml-nameid.properties file currently has no properties defined
(they’re all commented out).

Then you're not using/suporting/issuing persistent NameIDs not wrapped
in a SAML Attribute and you shouldn't care about that file.

If I were to add "idp.persistentId.sourceAttribute =
ucsfeduidnumber" to the properties, what value would I need to
specify for the “idp.persistentId.useUnfilteredAttributes” and
“idp.persistentId.algorithm” properties to prevent the ePTID from
changing?

None of this matters for your attribute-resolver-defined NameIDs.
(Having said that, the only thing you'd likely have to change is to set
idp.persistentId.encoding to BASE64.)

Also, would switching to using the properties instead of the data
connector defined sourceAttributeID change the behavior of the data
sent by the shibboleth.SAML2AttributeSourcedGenerator, for which we
have a number of attributeSourceIds defined in the saml-nameid.xml
file?

I'd have to re-read that a few times but the saml-nameid.* config
mechanism will NOT give you an eduPersonTargetedID *attribute*.
If SPs positively require that then you can't use saml-nameid.*, at
least not alone.

-peter
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwIGaQ&c=iORugZls2LlYyCAZRB3XLg&r=nu8TjafRyATXiCWMkFtf5v6w2YFX7dlXPahFfE1PUk0&m=09AFWFqqwbyZsMojOI-ub44juIcC4aWVMBuSWX69ik8&s=I9J_4Bh9po6B_YACkItAx_LmEwKuScTNjEq5YjGPTic&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200203/8e02188c/attachment.html>