urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Peter Schober peter.schober at univie.ac.at
Sun Sep 20 13:36:31 UTC 2020


* Joshua Brodie <josbrodie at gmail.com> [2020-09-20 01:59]:
> I am on another conundrum -- is that I do not know where it is set
> to use EPTI as
> 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'.

Again, the question doesn't make any sense to me. There's nothing
"using ePTID as persistent NameID", if anything it's the reverse: A
SAML 2.0 persistent NameID is (quite literally) wrapped into an
eduPersonTargetedID attribute.

Here's my own attribute definition, using non-deprecated syntax and
with an excplicit nameIdFormat XML-attribute -- which I don't see in
your config snippet:

  <AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    <InputDataConnector ref="computed" attributeNames="ComputedID" />
    <AttributeEncoder xsi:type="SAML1XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" encodeType="false" />
    <AttributeEncoder xsi:type="SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" encodeType="false" />
  </AttributeDefinition>

The referenced DataConnector looks like this:

  <DataConnector id="computed" xsi:type="ComputedId" generatedAttributeID="ComputedID"
                 salt="%{idp.persistentId.salt}" algorithm="%{idp.persistentId.algorithm:SHA}"
                 encoding="BASE64">
    <InputDataConnector ref="myLDAP" attributeNames="%{idp.persistentId.sourceAttribute}" />
  </DataConnector>

> However, I am unsure why I can't override
> 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' in 'saml-nameid.xml
> with another source ID for a particular service (all other NmaeID formats I
> can overide, however not
> 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent').

Sorry, I don't follow.
http://www.catb.org/~esr/faqs/smart-questions.html#goal

> We have a partner organization that has merged with us -- and I
> require to leverage their immutable identifier, now stored in our
> AD, as 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' for a
> particular SP.

If I (at last!) understand this correctly all you're trying to do is
send a custom attribute value out as a persistent NameID (no matter
how that would violate the specification you're pretending to follow)?
Then this has nothing at all to do with the eduPersonTargetedID
attribute or your configuration for it.

You'd do it as it sounds like you have been trying to do (add a <bean
parent="shibboleth.SAML2AttributeSourcedGenerator" with the correct
p:format and p:attributeSourceIds, probably also setting
p:omitQualifiers="true").

The only thing that would be special, I think, is the need to prevent the
standard <ref bean="shibboleth.SAML2PersistentGenerator" /> from
applying in the case of the broken SP.
So you'd probably have to define an activation condition on the bean
(reference) for persistent NameIDs in your conf/saml-nameid.xml.

Something like:
- <ref bean="shibboleth.SAML2PersistentGenerator" />
+ <bean parent="shibboleth.SAML2PersistentGenerator" p:activationCondition-ref="NOT_BrokenSp" />

With "NOT_BrokenSp" in your global.xml looking something like:

<bean id="NOT_BrokenSp" parent="shibboleth.Conditions.NOT">
    <constructor-arg>
        <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="https://your.example.com/broken/sp" />
    </constructor-arg>
</bean>

Hopefully there will be are other, less convoluted ways to do that.
(activationConditions and Spring are not my strong suit.)

-peter


More information about the users mailing list