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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Joshua Brodie
Hi All:

I had posted on this a while back and was unfortunately side-lined :(

For whatever reason, I can change the source value for 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' -- all others NameID formats I can do so via - saml-nameid.xml 9activationCondition based on the SP).

However 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' seems to be fixed to EPTI no matter what I do. Any hints on where to look would be much appreciated. Thanks.



--
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: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Peter Schober
* Joshua Brodie <[hidden email]> [2020-09-08 20:48]:
> I had posted on this a while back and was unfortunately side-lined :(

Well, you asked about sending email address values with the
'persistent' NameID format and were shot down rightfully, as that's
invalid. Here's a quote from the spec, SAML core, p.86[1]:

> 8.3.7 Persistent Identifier
> URI:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
>
> Indicates that the content of the element is a persistent opaque
> identifier for a principal that is specific to an identity provider
> and a service provider or affiliation of service
> providers. [E86]Persistent name identifiers generated by identity
> providers MUST be constructed using values that have no discernible
> correspondence with the subject's actual identity (for example,
> username). [...]
> The intent is to create a non-public, pair-wise pseudonym to prevent
> the discovery of the subject's identity or activities.

Email addresses violate that intent and those MUST requirements.

If you need to be sending email addresses as NameIDs then there's even
a matching NameID format defined in the spec, see 8.3.2, on p.85 of
that PDF.[1]

> However 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' seems
> to be fixed to EPTI no matter what I do.

Could you explain what the above means, exactly?
The new-for-IDPv3 saml-nameid.* mechanism does *not* create any
eduPersonTargetedID (nor any other) *attributes*, you'd have to create
those yourself in the attribute-resolver.
So as written the above is nonsensical to me.

-peter

[1] https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf
--
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: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Joshua Brodie
Hi Peter:

Thank you for your email.

>Well, you asked about sending email address values with the
'persistent' NameID format and were shot down rightfully

Yes, faster than a speeding bullet :)

I understand and appreciate the feedback.

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'. Unfortunately we have had layoffs, and I am spread thin -- sincere apologies for long delays in replies ;)

We have EPIT to read from the 'generatedAttributeID' below:

<resolver:DataConnector id="myStoredId" xsi:type="dc:StoredId" generatedAttributeID="persistentID" sourceAttributeID="%{idp.persistentId.sourceAttribute}"  queryTimeout="PT5S" transactionRetries="3" retryableErrors="72000 23000">
<resolver:Dependency ref="%{idp.persistentId.sourceAttribute}" />
<resolver:FailoverDataConnector ref="myStoredId-staticfailoverconnector"/>
<dc:BeanManagedConnection>OracleDataSource</dc:BeanManagedConnection>
     </resolver:DataConnector>

<resolver:AttributeDefinition id="eduPersonTargetedID" xsi:type="ad:SAML2NameID" sourceAttributeID="persistentID">
       <resolver:Dependency ref="myStoredId" />
       <resolver:AttributeEncoder xsi:type="enc:SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />
   </resolver:AttributeDefinition>

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'). 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.

I have search all over and can't find a smoking gun -- unless it is above and I am not understanding it.

Thanks.

On Tue, 8 Sep 2020 at 13:58, Peter Schober <[hidden email]> wrote:
* Joshua Brodie <[hidden email]> [2020-09-08 20:48]:
> I had posted on this a while back and was unfortunately side-lined :(

Well, you asked about sending email address values with the
'persistent' NameID format and were shot down rightfully, as that's
invalid. Here's a quote from the spec, SAML core, p.86[1]:

> 8.3.7 Persistent Identifier
> URI:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
>
> Indicates that the content of the element is a persistent opaque
> identifier for a principal that is specific to an identity provider
> and a service provider or affiliation of service
> providers. [E86]Persistent name identifiers generated by identity
> providers MUST be constructed using values that have no discernible
> correspondence with the subject's actual identity (for example,
> username). [...]
> The intent is to create a non-public, pair-wise pseudonym to prevent
> the discovery of the subject's identity or activities.

Email addresses violate that intent and those MUST requirements.

If you need to be sending email addresses as NameIDs then there's even
a matching NameID format defined in the spec, see 8.3.2, on p.85 of
that PDF.[1]

> However 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' seems
> to be fixed to EPTI no matter what I do.

Could you explain what the above means, exactly?
The new-for-IDPv3 saml-nameid.* mechanism does *not* create any
eduPersonTargetedID (nor any other) *attributes*, you'd have to create
those yourself in the attribute-resolver.
So as written the above is nonsensical to me.

-peter

[1] https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
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: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Peter Schober
* Joshua Brodie <[hidden email]> [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
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]