[Shib-Users] eduPersonTargetedID wire-format

[Peter Schober]

I'm recieving eduPersonTargetedIDs (as a SAML2 attribute) from a
simpleSAMLphp IdP that's sending only the user-identiying part (the
"pseudo-random values") as a simple string value, not the complex XML
attribute with the NameQualifier and SPNameQualifier attributes.
So instead of, say:

<saml:Attribute
FriendlyName="eduPersonTargetedID"
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>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://idp.example.org/shibboleth"
SPNameQualifier="https://sp.example.org/shibboleth">garbledbase64encodedfoo==</saml:NameID>
</saml:AttributeValue>
</saml:Attribute>

I just get:

<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10">
<saml:AttributeValue>someothergarbledprobablyhexencodedfoo</saml:AttributeValue>
</saml:Attribute>

My questions are:

1. How should I deal with this?

Section 8.3.7 of SAMLCore has "if present, MUST", so the specs
explicitly allow for their omission:

"It MAY be omitted if the value can be derived from the context of
the message containing the element, such as the issuer of a
protocol message or an assertion containing the identifier in its
subject."

But this is clearly undesirable, because it practically makes the
eduPersonTargetedID non-persistent: if the issuing IdP's entityId ever
changed, I'd be substituting the (new) Issuer's entityId for the
missing NameQualifier, hence breaking all existing
eduPersonTargetedIDs in my application. (Even though the most likely
part of the eduPersonTargetedID to change is the user-identifying
part, not the IdP's entityId. But still.)
Also in delegation szenarios I would expect this to be a problem,
since the original issuer could get "lost" (but I don't know enough
about this).

2. Ignoring for the moment that (to my current understanding) it's not
a good idea to substitute the assertion's Issuer for the missing
NameQualifier value: is it currently possible to change the decoding
config in the attribute-map.xml to get the NameQualifier (the IdPs
entityId) from somewhere else?
In other words: are there other variables accessible from the
attribute-map.xml than $NameQualifier and $SPNameQualifier?
Or would one have to do this in the applicaton, using the
"Shib-Identity-Provider" envvar, for example?

3. If there's a clear answer to question no. 1 (that deviates from the
way simpleSAMLphp currently seems to work), should this be
communicated to simpleSAMLphp developers? (If it's not a
misconfiguration on part of the deployers, of course.)

-peter

--
peter....@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2009-05-28 14:20]:

> I just get:
>
> <saml:Attribute
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10">
> <saml:AttributeValue>someothergarbledprobablyhexencodedfoo</saml:AttributeValue>
> </saml:Attribute>
>
> My questions are:
>
> 1. How should I deal with this?
>
> Section 8.3.7 of SAMLCore has "if present, MUST", so the specs
> explicitly allow for their omission:

I mixed up two differnet things above. SAMLCore only deals with
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, which is not
what the IdP sends (so it simply doen't apply).
Logically only the eduPerson schema governs the use of eduPerson
attributes (urn:oid:1.3.6.1.4.1.5923.1.1.1.10) and the most
specific info I found in 200806 was:

"The value is "qualified" by these two namespaces and need not be
unique outside them. Logically, the attribute value is made up of
the triple of an identifier, the identity provider, and the service
provider(s)."

This sounds like the IdP should really send this as a triple on the
wire, but not in a very strict or formal sense.
-peter

[Scott Cantor]

Peter Schober wrote on 2009-05-28:
> I mixed up two differnet things above. SAMLCore only deals with
> urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, which is not
> what the IdP sends (so it simply doen't apply).

No, but SAML core defines that NameID structure, and the SAML 2 profile for
the attribute named "urn:oid:1.3.6.1.4.1.5923.1.1.1.10" requires that the
value be a NameID with that format.

> This sounds like the IdP should really send this as a triple on the
> wire, but not in a very strict or formal sense.

No, but the I2MI SAML attribute profile is quite strict about it. The
eduPerson definition for that attribute is dealing in abstract data models.
Abstractly, it's a triple. Concretely in SAML 2, it's a NameID. I don't
recall whether we added language insisting that the qualifiers be included,
but I might have.

-- Scott

[Scott Cantor]

> I'm recieving eduPersonTargetedIDs (as a SAML2 attribute) from a
> simpleSAMLphp IdP that's sending only the user-identiying part (the
> "pseudo-random values") as a simple string value, not the complex XML
> attribute with the NameQualifier and SPNameQualifier attributes.

Then it's not passing a legal value for that attribute.

> I just get:
>
> <saml:Attribute
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10">
>
>
<saml:AttributeValue>someothergarbledprobablyhexencodedfoo</saml:AttributeVa
> lue>
> </saml:Attribute>

That's definitely illegal according to the definition of that URI.

> My questions are:
>
> 1. How should I deal with this?

Reject it, which I would think the SP should be doing for you.

> Section 8.3.7 of SAMLCore has "if present, MUST", so the specs
> explicitly allow for their omission:

Yes, but leaving aside whether the qualifiers can be ommitted (it's
technically legal but not a good practice when using the SAML attribute
form), you can't just leave out the NameID element itself.

> But this is clearly undesirable, because it practically makes the
> eduPersonTargetedID non-persistent: if the issuing IdP's entityId ever
> changed, I'd be substituting the (new) Issuer's entityId for the
> missing NameQualifier, hence breaking all existing
> eduPersonTargetedIDs in my application. (Even though the most likely
> part of the eduPersonTargetedID to change is the user-identifying
> part, not the IdP's entityId. But still.)

That's true, although I would question the liklihood of too many deployers
actually realizing they need to somehow preserve the old entityID for the
purposes of the attribute values. Changing an entityID should simply never
happen barring the sale of a domain name, it's really that simple.

> Also in delegation szenarios I would expect this to be a problem,
> since the original issuer could get "lost" (but I don't know enough
> about this).

Right, that's why the SAML spec tries to say that if it's ever in "doubt",
you should pretty much just include them.

All of that is beside the point here, since your example is just flat
invalid anyway.

> 2. Ignoring for the moment that (to my current understanding) it's not
> a good idea to substitute the assertion's Issuer for the missing
> NameQualifier value: is it currently possible to change the decoding
> config in the attribute-map.xml to get the NameQualifier (the IdPs
> entityId) from somewhere else?

It wouldn't matter here, because again, what you got isn't a NameID,
therefore it's invalid for that attribute name. But to answer the question,
the SP does in fact plug in the "asserting party entityID" into the
NameQualifier if it isn't present, when using the NameID attribute decoder.
The reason you aren't getting it is that it's NOT a NameID. If it's decoding
it at all, something's off. My code shouldn't be doing that.

> In other words: are there other variables accessible from the
> attribute-map.xml than $NameQualifier and $SPNameQualifier?

What's available in the case of a NameID are the values you can get from a
NameID, so that includes Format and SPProvidedID as well as those two.
That's all.

> 3. If there's a clear answer to question no. 1 (that deviates from the
> way simpleSAMLphp currently seems to work), should this be
> communicated to simpleSAMLphp developers? (If it's not a
> misconfiguration on part of the deployers, of course.)

If there's some baked in code that's producing that attribute construct,
then yes, it's a bug.

-- Scott

[Scott Cantor]

Maybe this goes without saying, but obviously all those "rules" about the
attribute aren't known to the SP per se, they're just preconfigured by
default as part of the extraction and filtering definitions for that
attribute name. If you altered the rules, you could obviously get it to
consume the attribute in any way you want to, but the essential problem is
that you can't decode the same named attribute differently based on the
issuer at this point.

I suppose one thing I could do is create a "Chaining" decoder that runs
multiple decoders in sequence until one of them "works", so in theory
multiple syntaxes could be handled for the same attribute.

But in the case of a simple string masquerading as a targetedID, you're
correct that there wouldn't be a way to "imply" the NameQualifier since the
Simple decoder wouldn't know about that concept. The application would have
to derive it from the Shib-Identity-Provider header.

All this craziness is why we use attribute profiles and why being strict
about them is the best way to preserve everybody's sanity.

-- Scott

[Peter Schober]

* Scott Cantor <cant...@osu.edu> [2009-05-28 17:18]:

> All this craziness is why we use attribute profiles and why being
> strict about them is the best way to preserve everybody's sanity.

Fully ACK. Thanks for clearing things up and answering all my
quesions, even if some of them where slightly off (i.e.: no
saml2:NameID as a value, no reason to go on about missing
NameQualifiers).

While I knew about the MACE-Dir Attribute Profile I somehow forgot to
check this as well and it indeed is very clear about this:

"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' as described
in section 8.3.7 of [SAML2Core]."

I'll have to ask Andreas/the simpleSAMLphp people about support for
the "MACE-Dir SAML Attribute Profiles".

Thanks,
-peter

[Scott Cantor]

Peter Schober wrote on 2009-05-28:

> While I knew about the MACE-Dir Attribute Profile I somehow forgot to
> check this as well and it indeed is very clear about this:
>
> "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' as described
> in section 8.3.7 of [SAML2Core]."

In light of that, it appears that I left the use of the qualifiers as in the
SAML standard, which means they're suggested in any possible case of
confusion, but can be omitted if the implied values would be correct. That's
problematic in the case of SPNameQualifier (the SP has to guess about what
the IdP thinks its name is), so the simple answer is just not to omit them.
If we ever get around to revising the profile, I'll try and remember it.

-- Scott