eduPersonTargetedId with SSP 1.14.6

[Enrico Cavalli]

Hello,

I’m struggling with an upgrade from SSP 1.11 to the last release version. Basically I’m getting (on the Service Provider)
empty eduPersonTargetedId


[urn:oid:1.3.6.1.4.1.5923.1.1.1.10] => Array
(
[0] => DOMNodeList Object
(
[length] => 0
)

)


Debugging the assertion this is what the IDP is passing

<saml2: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">
<saml2:AttributeValue>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://XXXXX" SPNameQualifier="https://YYYYYYY">u52GUodAoKydc2qSy344ml25Yi4=</saml2:NameID>
</saml2:AttributeValue>
</saml2:Attribute>

With simplesaml 1.11 this gets decoded correctly

Do you have any suggestions ? Maybe

IDP is shibboleth. I suppose everything is ok on the IDP (testing with federation test SP is ok).

Any help would be appreciated.

Thank you very much,

Enrico

--
Enrico Cavalli - enrico....@gmail.com
jabber: enrico....@gmail.com skype: enricocavalli
PGP Fingerprint: 3762 7B1B 743E 029C 8F94 8ADE BC4B 43A7 0485 30E5

[Jaime Perez Crespo]

Ciao Enrico!

On 26 Jul 2016, at 14:44 PM, Enrico Cavalli <enrico....@gmail.com> wrote:
> Hello,
>
> I’m struggling with an upgrade from SSP 1.11 to the last release version. Basically I’m getting (on the Service Provider)
> empty eduPersonTargetedId
>
> [urn:oid:1.3.6.1.4.1.5923.1.1.1.10] => Array
> (
> [0] => DOMNodeList Object
> (
> [length] => 0
> )
> )

This is a bug.

> Debugging the assertion this is what the IDP is passing
>
> <saml2: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">
> <saml2:AttributeValue>
> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://XXXXX" SPNameQualifier="https://YYYYYYY">u52GUodAoKydc2qSy344ml25Yi4=</saml2:NameID>
> </saml2:AttributeValue>
> </saml2:Attribute>

And this is normal:

http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonTargetedID

> With simplesaml 1.11 this gets decoded correctly

Actually, it was not decoded correctly. You were getting the text content (in this case, “u52GUodAoKydc2qSy344ml25Yi4=“) of the NameID element, but that’s wrong as it means ignoring all other meaningful data included in the attributes value (as the NameQualifier and the SPNameQualifier attributes in this case).

This is why the behaviour was changed some time ago, specifically, in PR #60 in the simplesamlphp/saml2 library:

https://github.com/simplesamlphp/saml2/pull/60

This is when the incorrect parsing of the value was fixed. However, this introduced a different issue. DOM objects cannot be serialized in PHP, so after getting the response and parsing it adequately, the session is serialized to save it and redirect to the original page that asked for authentication, and then the value is lost. When the session is deserialized, an empty DOM object is created instead. Note that fixing this won’t get back to the previous behaviour, and you will still need to parse the value manually, but at least you should get the value and not an empty list.

I’ll file a bug so that we can solve the issue, and probably have a new release with the bugfix, since this affects potentially al SimpleSAMLphp service providers connected to a Shibboleth IdP (and a SimpleSAMLphp IdP configured to encode eduPersonTargetedID using a NameID, and probably other software too).

Thanks for letting us know!

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Enrico Cavalli]

On 07/27/2016 04:35 PM, Jaime Perez Crespo wrote:
> Ciao Enrico!
>

Ciao!

> And this is normal:
>
> http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonTargetedID
>
>> With simplesaml 1.11 this gets decoded correctly
>
> Actually, it was not decoded correctly. You were getting the text content (in this case, “u52GUodAoKydc2qSy344ml25Yi4=“) of the NameID element, but that’s wrong as it means ignoring all other meaningful data included in the attributes value (as the NameQualifier and the SPNameQualifier attributes in this case).
>

It perfectly makes sense, it's wrong but correct :) it's easy to make
sense of it at least :)

he issue, and probably have a new release with the bugfix, since this
affects potentially al SimpleSAMLphp service providers connected to a
Shibboleth IdP (and a SimpleSAMLphp IdP configured to encode
eduPersonTargetedID using a NameID, and probably other software too).
>
> Thanks for letting us know!

Thank you for your help. I tought of a configuration error and I'm
really not good with nameids/standards and so on.

[Peter Schober]

* Jaime Perez Crespo <jaime...@uninett.no> [2016-07-27 16:35]:

> > Debugging the assertion this is what the IDP is passing
> >
> > <saml2: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">
> > <saml2:AttributeValue>
> > <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://XXXXX" SPNameQualifier="https://YYYYYYY">u52GUodAoKydc2qSy344ml25Yi4=</saml2:NameID>
> > </saml2:AttributeValue>
> > </saml2:Attribute>
>
> And this is normal:
>
> http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonTargetedID

Or more to the point 3.3.1.1 in
http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf

"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]."

On can argue with saml2int (section 7) that use of the
eduPersonTargetedID SAML Attribute within SAML2.0 itself is legacy and
should be avoided: The NameID should be sent in the Assertion's
Subject element, not as SAML Attribute.
That may or may not make a difference for this issue, since the NameID
in the other place is still an XML element, not a string.

> I’ll file a bug so that we can solve the issue, and probably have a
> new release with the bugfix, since this affects potentially al
> SimpleSAMLphp service providers connected to a Shibboleth IdP (and a
> SimpleSAMLphp IdP configured to encode eduPersonTargetedID using a
> NameID, and probably other software too).

Note that as per above a NameID element is the *only* correct value of
an eduPersonTargetedID attribute. So the only SSP SPs /not/ breaking
would be those recieving /invalid/ values. :-\
-peter

[Jaime Perez Crespo]

Hi Peter,

On 27 Jul 2016, at 17:06 PM, Peter Schober <peter....@univie.ac.at> wrote:
> Or more to the point 3.3.1.1 in
> http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf
>
> "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 missed the MUST, thanks for making it explicit.

> On can argue with saml2int (section 7) that use of the
> eduPersonTargetedID SAML Attribute within SAML2.0 itself is legacy and
> should be avoided: The NameID should be sent in the Assertion's
> Subject element, not as SAML Attribute.
> That may or may not make a difference for this issue, since the NameID
> in the other place is still an XML element, not a string.

That’s irrelevant, the issue is still there, and according to my experience the vast majority is using the attribute instead of the NameID in the Subject element.

> Note that as per above a NameID element is the *only* correct value of
> an eduPersonTargetedID attribute. So the only SSP SPs /not/ breaking
> would be those recieving /invalid/ values. :-\

Indeed. That reinforces my idea that we should have a bugfix release with this.

By the way, this also makes me think we should have an authproc filter ensuring the “quality” of the attributes received, making sure for example that if we have an eduPersonTargetedID, it’s value is a NameID and nothing else.

[Peter Schober]

* Jaime Perez Crespo <jaime...@uninett.no> [2016-07-27 17:36]:

> On 27 Jul 2016, at 17:06 PM, Peter Schober <peter....@univie.ac.at> wrote:
> > That may or may not make a difference for this issue, since the NameID
> > in the other place is still an XML element, not a string.
>
> That’s irrelevant, the issue is still there, and according to my
> experience the vast majority is using the attribute instead of the
> NameID in the Subject element.

Yeah, I'm guessing the problem doesn't surface much with other NameID
formats since either the qualifiers are not there (e.g. email) or we
have no real interest in the NameID value(s) at all (e.g. transients).
So the same issue applies (as I speculated above) if the NameID is in
the "proper" place of the SAML Assertion? That certainly sucks.

> Indeed. That reinforces my idea that we should have a bugfix release
> with this.

I really wish we had a way to treat the
persistent-NameID-in-one-of-2-places issue more transparently for
deployers. E.g. the Shib SP will stuff it into the same internal
attribute no matter where it came from. That allows IDPs to move from
one (legacy) way of sending it to another (saml2int-recommended)
without the SP or the application protected by it even noticing.

As it is, NameID-access in SSP is totally separate from attribute
value access, which is a stand one can take ("they're different
things") but which really hurts cases like this, where the same data
(identical NameID elements, really) could be in one of two
places. If you as the deployer have to use 2 different API calls to
check both places you can be sure not all deployers (that need to
handle persistent NameIDs) will do that. Which hurts interop.

> By the way, this also makes me think we should have an authproc
> filter ensuring the “quality” of the attributes received, making
> sure for example that if we have an eduPersonTargetedID, it’s value
> is a NameID and nothing else.

Well, there's always Postel's law (robustness principle) and people
should at least get the tools to fix locally what /can/ be fixed.
-peter

[Jaime Perez Crespo]

Hi Peter,

On 27 Jul 2016, at 17:58 PM, Peter Schober <peter....@univie.ac.at> wrote:
> Yeah, I'm guessing the problem doesn't surface much with other NameID
> formats since either the qualifiers are not there (e.g. email) or we
> have no real interest in the NameID value(s) at all (e.g. transients).
> So the same issue applies (as I speculated above) if the NameID is in
> the "proper" place of the SAML Assertion? That certainly sucks.

Oh, no, I meant that as long as you are using the eduPersonTargetedID attribute (and you are getting it properly encoded as a NameID), then you are affected by this issue.

NameIDs inside the Subject element are fine, because they are always parsed as XML.

> I really wish we had a way to treat the
> persistent-NameID-in-one-of-2-places issue more transparently for
> deployers. E.g. the Shib SP will stuff it into the same internal
> attribute no matter where it came from. That allows IDPs to move from
> one (legacy) way of sending it to another (saml2int-recommended)
> without the SP or the application protected by it even noticing.

That would be nice. My suspicion is that not many people are using the NameID coming inside the Subject element. That would make it easier to just drop the NameID inside the eduPersonTargetedID attribute. An authproc filter is again a good candidate for this, so that we are not forcing people to change something that’s working for them.

> As it is, NameID-access in SSP is totally separate from attribute
> value access, which is a stand one can take ("they're different
> things") but which really hurts cases like this, where the same data
> (identical NameID elements, really) could be in one of two
> places.

Actually, at least SimpleSAMLphp can perfectly generate two completely different NameIDs, one for the Subject element and one for the eduPersonTargetedID. I even realized a couple of days ago that that’s what we are doing in the Feide IdP. I’m uncertain whether the spec forbids that behaviour or not (I don’t think so), though I would assume any interop profiles to do that.

> If you as the deployer have to use 2 different API calls to
> check both places you can be sure not all deployers (that need to
> handle persistent NameIDs) will do that. Which hurts interop.

Agreed.

>> By the way, this also makes me think we should have an authproc
>> filter ensuring the “quality” of the attributes received, making
>> sure for example that if we have an eduPersonTargetedID, it’s value
>> is a NameID and nothing else.
>
> Well, there's always Postel's law (robustness principle) and people
> should at least get the tools to fix locally what /can/ be fixed.

Just another thing we should do, on top of a huge queue where almost nobody is getting stuff out of :-)

[Enrico Cavalli]

> Il giorno 28 lug 2016, alle ore 10:01, Jaime Perez Crespo <jaime...@uninett.no> ha scritto:
>>
>
> Actually, at least SimpleSAMLphp can perfectly generate two completely different NameIDs, one for the Subject element and one for the eduPersonTargetedID. I even realized a couple of days ago that that’s what we are doing in the Feide IdP. I’m uncertain whether the spec forbids that behaviour or not (I don’t think so), though I would assume any interop profiles to do that.

Excuse me if I’m not precise and probably I’m not adding any useful information to the discussion,
but I confirm this is the behavior I observe from shibboleth IDPs of the Italian federation IDEM.

I’m getting a transient NameID in the Subject element and the persistent one inside the eduPersonTargetedID encoded as in the example.
By the way, when I configure simplesaml as IDP in the federation, those two nameid are generated in this way and as IDP the configuration
is considered valid by the federation.

Regards,
Enrico.

[Jaime Perez Crespo]

That’s actually valuable feedback, thanks Enrico!

At least now we know we are not breaking something by allowing two different NameIDs in an assertion. Or at least, if we do, Shibboleth is doing it too, so hopefully it’s not a big issue.

In any case, I have a fix for the issue here, and I’ll be porting it to 1.14 through the day.

On 28 Jul 2016, at 10:26 AM, Enrico Cavalli <enrico....@gmail.com> wrote:
> Excuse me if I’m not precise and probably I’m not adding any useful information to the discussion,
> but I confirm this is the behavior I observe from shibboleth IDPs of the Italian federation IDEM.
>
> I’m getting a transient NameID in the Subject element and the persistent one inside the eduPersonTargetedID encoded as in the example.
> By the way, when I configure simplesaml as IDP in the federation, those two nameid are generated in this way and as IDP the configuration
> is considered valid by the federation.

[Peter Schober]

* Jaime Perez Crespo <jaime...@uninett.no> [2016-07-28 10:01]:

> NameIDs inside the Subject element are fine, because they are always
> parsed as XML.

Ah, OK, that's great then! That also means IDPs sending it according
to saml2int (that number will get higher with IDPv3 deployments taking
off, I'm expecting) will not cause any issues for deployed SPs.

> Actually, at least SimpleSAMLphp can perfectly generate two
> completely different NameIDs, one for the Subject element and one
> for the eduPersonTargetedID. I even realized a couple of days ago
> that that’s what we are doing in the Feide IdP. I’m uncertain
> whether the spec forbids that behaviour or not (I don’t think so),
> though I would assume any interop profiles to do that.

It's certainly legal and there's even a (fringe) use-case for that
specific scenario (transients in the Subject, persistent in
eduPersonTargetedID attribute), when the IDP wants/needs to provide a
persistent NameID to the SP but is not willing/able to *reverse*
that NameID from incoming messages (e.g. attribute queries) into a
locally meaningful identifier.
The main cause for that is generating persistent NameIDs dynamically
from (salting and) hashing some other attribute at the IDP, *without*
persisting the values into an RDBMS (together with a mapping to the
local subject identifier it was generated from). Now when an IDP
entity also announcing support for attribute queries (or SLO) is then
presented with that persistent (but not persisted) NameID it cannot
easily reverse that salted hash into the local subject identifier to
resolve attributes (or identify sessions to terminate, in case of SLO).

But that model shouldn't really be promoted (as persistent NameIDs
generate that way may not be so persistent after all, and with just an
algorithm you don't really have any tools at hand to "fix" the
occasional error, or revoke identifiers if needed) and so the whole
eduPersonTargetedID attribute should be deprecated by the community
for SAML2 usage.
I'm not convinced it's worth the effort myself, and this will probably
not be completed before people start moving off SAML, but the current
situation is bad enough (and saml2int clear enough) that doing it only
the SAML-intended way (Subject of the Assertion) seems the least worse
forward (rather than continuing with the mess).

> Just another thing we should do, on top of a huge queue where almost
> nobody is getting stuff out of :-)

ACK. Maybe some federation or organisation is willing to contribute
code, or finance someone to do that, to get some of that done.
(As an aside: The GEANT "Greenhouse" activity might help with that a
bit, be sure to have someone represent SSP there.)

-peter

[Jaime Perez Crespo]

Hi Peter!

On 28 Jul 2016, at 11:05 AM, Peter Schober <peter....@univie.ac.at> wrote:
>> Just another thing we should do, on top of a huge queue where almost
>> nobody is getting stuff out of :-)
>
> ACK. Maybe some federation or organisation is willing to contribute
> code, or finance someone to do that, to get some of that done.
> (As an aside: The GEANT "Greenhouse" activity might help with that a
> bit, be sure to have someone represent SSP there.)

Yes, I’ve been following the progress of the Greenhouse indeed, and even attending some meetings. In fact, we are about to start a project up here to try to evaluate how to use the Greenhouse basing on the experience gathered by the Filesender project.

We’ll see where that goes. Hopefully somewhere productive and enabling more people to collaborate or contribute in any way.

In any case, I definitely think it’s important to remember that open source projects need from the collaboration of their users to survive.