1.13.2: eduPersonTargetedID not working correctly?

[Stefan Winter]

Hello,

with my SAML 2.0 IdP, I'm trying to generate eduPersonTargetedIDs, and
to pass the Interfederation Attribute Test.

https://attribute-viewer.aai.switch.ch/interfederation-test/

I fail for eduPersonTargetedID, and can't figure out why (or rather,
how to configure so that it would work).

I use the following authproc.idp in config.php:

// generate a eduPersonTargetedId, unfortunately in pretty-print format

20 => array(
'class' => 'core:TargetedID',
'attributename' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
'nameId' => TRUE,
),

// convert eduPersonTargetedId to its URN

25 => array(
'class' => 'core:AttributeMap',
'eduPersonTargetedID' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10',
),


I understand that I need the 'nameId' parameter because the persistent
ID should be an attribute, *and* as a name ID in the assertion.

Now, the resulting SAML message does not look like it really does what
it should. Using SAMLTracer, I get this for eduPersonTargetedID:

<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">&lt;saml:NameID xmlns:saml=&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot; NameQualifier=&quot;https://clueless.restena.lu/simplesamlphp/saml2/idp/metadata.php&quot; SPNameQualifier=&quot;https://attribute-viewer.aai.switch.ch/interfederation-test/shibboleth&quot; Format=&quot;urn:oasis:names:tc:SAML:2.0:nameid-format:persistent&quot;&gt;c5374b6ad187dfcc839c2043c0af63ce13c82854&lt;/saml:NameID&gt;</saml:AttributeValue>
</saml:Attribute>

That's an XML blob inside AttributeValue? Is that intentional?

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

[Peter Schober]

* Stefan Winter <stefan...@restena.lu> [2015-09-23 12:13]:

> I understand that I need the 'nameId' parameter because the
> persistent ID should be an attribute, *and* as a name ID in the
> assertion.

Note that this may be what the optional eduGAIN attribute profile
presribes, but others (incl the editor of the SAML2 spec) have called
this the "worst possible option".
Short version: for SAML2.0 stick the persistent NameID into the
Assertion's Subject, done. eduPersonTargetedId was needed for SAML1
and should be deprecated for SAML2 usage.

> Now, the resulting SAML message does not look like it really does what
> it should. Using SAMLTracer, I get this for eduPersonTargetedID:
>
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml:AttributeValue xsi:type="xs:string">&lt;saml:NameID

It's a string (so any XML get's encoded), but the required content of
that attribute value is an XML structure, not a string.
I have this in metadata/saml20-idp-hosted.php:

'attributeencodings' => array('urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw'),

> That's an XML blob inside AttributeValue? Is that intentional?

It's not, it's a string. If were correct it'd be XML:

"The <saml2:AttributeValue> element's content MUST be a <saml2:NameID>
element with a Format XML attribute of

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

http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf

But better to not send it as Attribute altogether,
-peter

[Stefan Winter]

Hello,

> I have this in metadata/saml20-idp-hosted.php:
>
> 'attributeencodings' => array('urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw'),

Great! This worked just fine.

> But better to not send it as Attribute altogether,

I like passing tests though. Am I correct in assuming that the presence
of the attribute does not do harm at least?

On the topic of Subject nameID: how do I "just stick" the ePTID in
there? Right now, SAML tracer has a value in <Subject> - but it does not
match the hash inside the ePTID attribute. I.e.:


<saml:Subject>
<saml:NameID
SPNameQualifier="https://attribute-viewer.aai.switch.ch/interfederation-test/shibboleth"
Format="urn:mace:shibboleth:1.0:nameIdentifier">
23eeb91325bb4a4fe0a571a61103aa56b4926374
</saml:NameID>...

But:

<saml:AttributeValue>
<saml:NameID
NameQualifier="https://clueless.restena.lu/simplesamlphp/saml2/idp/metadata.php"
SPNameQualifier="https://attribute-viewer.aai.switch.ch/interfederation-test/shibboleth"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
c5374b6ad187dfcc839c2043c0af63ce13c82854
</saml:NameID></saml:AttributeValue>

Should the values not at least match?

Stefan

[Peter Schober]

* Stefan Winter <stefan...@restena.lu> [2015-09-23 13:24]:

> Am I correct in assuming that the presence of the attribute does not
> do harm at least?

Well, assumind you did it correctly at least all Shibboleth SPs would
then have the value twice in the same internal representation
(persistentId environment variable, by default). I.e., it becomes
multi-valued, with two identical values. (Deduplicating at that code
path seems non-trival and so has not happened so far.)

> On the topic of Subject nameID: how do I "just stick" the ePTID in
> there? Right now, SAML tracer has a value in <Subject> - but it does
> not match the hash inside the ePTID attribute. I.e.:
>
> <saml:Subject>
> <saml:NameID
> SPNameQualifier="https://attribute-viewer.aai.switch.ch/interfederation-test/shibboleth"
> Format="urn:mace:shibboleth:1.0:nameIdentifier">
> 23eeb91325bb4a4fe0a571a61103aa56b4926374
> </saml:NameID>...
>
> But:
>
> <saml:AttributeValue>
> <saml:NameID
> NameQualifier="https://clueless.restena.lu/simplesamlphp/saml2/idp/metadata.php"
> SPNameQualifier="https://attribute-viewer.aai.switch.ch/interfederation-test/shibboleth"
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
> c5374b6ad187dfcc839c2043c0af63ce13c82854
> </saml:NameID></saml:AttributeValue>
>
> Should the values not at least match?

Yes, they should be identical.

Note that not only is Subject/NameID/@Format wrong (and the
NameQualifier is missing, though it's optional), the string value
actually differs.
-peter

[Stefan Winter]

Hi,

>> Should the values not at least match?
>
> Yes, they should be identical.
>
> Note that not only is Subject/NameID/@Format wrong (and the
> NameQualifier is missing, though it's optional), the string value
> actually differs.

The SP has this in his (metarefreshed, converted) metadata:

'NameIDFormat' => 'urn:mace:shibboleth:1.0:nameIdentifier',

so my IdP uses this format.

After proper configuration, the *value* generated is a persistentID, and
is properly repeated inside the ePTID attribute.

I've also set NameIDFormat in my idp-hosted to the SAML 2.0 persistent
one, so unless an SP explicitly requests transient, the IdP will
generate the persistent format.

Phew. Thanks for the help!

[Peter Schober]

* Stefan Winter <stefan...@restena.lu> [2015-09-23 15:36]:

> The SP has this in his (metarefreshed, converted) metadata:
>
> 'NameIDFormat' => 'urn:mace:shibboleth:1.0:nameIdentifier',
>
> so my IdP uses this format.

That's very likely a copy/paste mistake from the SP, carrying over
some legacy stuff.

> I've also set NameIDFormat in my idp-hosted to the SAML 2.0 persistent
> one, so unless an SP explicitly requests transient, the IdP will
> generate the persistent format.

Jfyi, I have this the other way round (NameIDFormat set to transient
in metadata/saml20-idp-hosted.php).
Great you could make it work. If you have any proposed changes for the
documentation please provide them (here or better via pull requests,
so they don't get lost).
-peter