RE: ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

Cantor, Scott E.
> The documentation for the ComputedIdConnector at
> indicates that, as of version 3.4, the sourceAttriubteID data connector attribute
> has been deprecated.

You just move into the modern InputAttributeDefinition or InputDataConnector syntax and specify the source attribute explicitly that way, that's all. The deprecation is just the syntax, nothing functional. We got rid of all the occurrences of sourceAttributeId that were in the top level elements.

> 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?

The properties in that file have no relevance to the generator that's based on attributes. The properties control persistent NameID generation and that generator is for custom NameIDs using other formats. The properties are used because we auto-configure the persistent NameID generator beans internally instead of exposing them in the XML file, whereas the AttributeSourcedGenerator beans are actually configured by you directly (unless you create your own properties to use).

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

Peter Schober
* Sheldon, Nathan I <[hidden email]> [2020-02-03 20:25]:
> The documentation for the ComputedIdConnector at
> https://wiki.shibboleth.net/confluence/display/IDP30/ComputedIdConnector
> 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://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

Cantor, Scott E.
> I’ll switch to using the InputDataConnector within the DataConnector definition
> then.

I may have overlooked the full scope of what you were doing, so if you're more explicit about exactly which syntaxes you're needing to maintain support for, I can probably be more specific about the "advisable" way to do them all.

The one that's really "please stop doing this" is the embedding of a NameID inside an AttributeValue, using those XMLObject AttributeEncoders, but that's not really going away, it's just a bad idea.

Also, the property-driven persistent NameID code will produce the same computed values as the ComputedId connector will, given the same salt and encodings, and all of the options supported on one will be (in V4) properly supported on the other.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

Peter Schober
* Cantor, Scott <[hidden email]> [2020-02-03 21:22]:
> The one that's really "please stop doing this" is the embedding of a
> NameID inside an AttributeValue, using those XMLObject
> AttributeEncoders, but that's not really going away, it's just a bad
> idea.

AFAIU the OP's case use of the Attribute is down to SPs currently
receiving those. If those SPs were of the Shibboleth implementation of
course they wouldn't even notice being switched over to the proper
format (using the saml-nameid.* mechanism) -- i.e, dumping the
wrapping SAML Attribute -- /unless/ the default config allowing for
that was sabotaged by the deployer...

But even that could be tested out "in advance" to some degree by using
the SP's session initiator and Session handler URLs, e.g.
https://sp.example.edu/Shibboleth.sso/Login?entityID=yourIDP&target=https://sp.example.edu/Shibboleth.sso/Session
before and after changing the IDP's config.
(Unless the deployer disabled the Session handler, too, though I have
rarely if ever seen that.)

Of course pretty much all hope is lost for non-Shibboleth SPs.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ePTID and ComputedId Persistence After IdP 3.3 -> 3.4 Upgrade

Peter Schober
In reply to this post by Cantor, Scott E.
* Sheldon, Nathan I <[hidden email]> [2020-02-03 20:25]:
> How do I maintain existing ePTID values for users after the 3.4
> upgrade so there is no interruption in service with the 6 SPs that
> rely on ePTID?

And don't forget about using the aacli (e.g. with the --saml2 option
to see the complete NameID XML in its full glory), both before and
after making any config changes + component reloads.

(And those config changes and reloads don't need to be run on your
prod IDP, of course: Any old test machine set up to load the same
metadata as your prod IDP and uses the same config will do. That
machine doesn't need to be reachable from anywhere, doesn't need a DNS
entry, etc.)

That way you can compare identifier values for arbitrary subjects,
verbatim, in advance, before ever deploying those changes to prod:

$ /opt/shibboleth-idp/bin/aacli.sh --saml2 -n SomeUserID -r https://sp.example.org/saml

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]