Exception "(EPTI) attribute value must be a NameID"

78 views
Skip to first unread message

José A. Accino

unread,
May 24, 2018, 7:47:16 AM5/24/18
to simple...@googlegroups.com
Hello.

To check for the IdP availability we are using a Nagios agent sending a
periodical request to a minimal, SimpleSAMLphp SP protected application
returning just two attributes, eduPersonTargetedID and mail.

This setup was running fine with SSp 1.14.x, but after upgrading to
1.15.4 (yes, a lot of weeks ago), the SP side
(...module.php/saml/sp/saml2-acs.php/test-idp) started to send that
exception message after returning from the authentication:

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
Backtrace:
1 www/_include.php:45 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: SAML2\Exception\RuntimeException: A
"urn:mace:dir:attribute-def:eduPersonTargetedID" (EPTI) attribute value
must be a NameID, none found for value no. "0"
Backtrace:
8 vendor/simplesamlphp/saml2/src/SAML2/Assertion.php:558
(SAML2\Assertion::parseAttributeValue)
...

Changing to test another attribute instead (let us say, ePPN) the issue
was quickly avoided to keep the test active, but the question remains
unsolved.

At first glance I thought it could be related to
https://github.com/simplesamlphp/simplesamlphp/issues/424, but an
identical test application running in another machine (with SSp 1.15.4
as well as SP) is getting correctly the ePTID value, and the same for
other ePTID aware SPs under Shibboleth in other services.

Any help?

Regards,
JA.

PS. BTW, I've been unable to get SAML Tracer to run with Firefox 60.0.1
on Mac Sierra OS.

Peter Schober

unread,
May 24, 2018, 8:11:13 AM5/24/18
to simple...@googlegroups.com
* José A. Accino <acc...@uma.es> [2018-05-24 13:47]:
> an identical test application running in another machine (with SSp
> 1.15.4 as well as SP) is getting correctly the ePTID value, and the
> same for other ePTID aware SPs under Shibboleth in other services.

Does the metadata your SSP IDP have on record for these SPs differ wrt
nameid handling?

-peter

Tom Scavo

unread,
May 24, 2018, 9:47:38 AM5/24/18
to simpleSAMLphp
On Thu, May 24, 2018 at 7:47 AM, José A. Accino <acc...@uma.es> wrote:
>
> SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
> Backtrace:
> 1 www/_include.php:45 (SimpleSAML_exception_handler)
> 0 [builtin] (N/A)
> Caused by: SAML2\Exception\RuntimeException: A
> "urn:mace:dir:attribute-def:eduPersonTargetedID" (EPTI) attribute value
> must be a NameID, none found for value no. "0"
> Backtrace:
> 8 vendor/simplesamlphp/saml2/src/SAML2/Assertion.php:558
> (SAML2\Assertion::parseAttributeValue)

I don't know what changed in SSP 1.15.4 but I do know that
"urn:mace:dir:attribute-def:eduPersonTargetedID" is a legacy name for
ePTID. Use "urn:oid:1.3.6.1.4.1.5923.1.1.1.10" instead. See the
MACE-Dir SAML Attribute Profiles [1] for details.

Hope this helps,

Tom

[1] http://macedir.org/docs/internet2-mace-dir-saml-attributes-200804a.pdf

Peter Schober

unread,
May 24, 2018, 9:51:40 AM5/24/18
to simpleSAMLphp
* Tom Scavo <trs...@gmail.com> [2018-05-24 15:47]:
> On Thu, May 24, 2018 at 7:47 AM, José A. Accino <acc...@uma.es> wrote:
> > SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
> > Backtrace:
> > 1 www/_include.php:45 (SimpleSAML_exception_handler)
> > 0 [builtin] (N/A)
> > Caused by: SAML2\Exception\RuntimeException: A
> > "urn:mace:dir:attribute-def:eduPersonTargetedID" (EPTI) attribute value
> > must be a NameID, none found for value no. "0"
> > Backtrace:
> > 8 vendor/simplesamlphp/saml2/src/SAML2/Assertion.php:558
> > (SAML2\Assertion::parseAttributeValue)
>
> I don't know what changed in SSP 1.15.4 but I do know that
> "urn:mace:dir:attribute-def:eduPersonTargetedID" is a legacy name for
> ePTID. Use "urn:oid:1.3.6.1.4.1.5923.1.1.1.10" instead. See the
> MACE-Dir SAML Attribute Profiles [1] for details.

Yeah, when the attribute name is
"urn:mace:dir:attribute-def:eduPersonTargetedID" and the protocol is
SAML1 the MACE-Dir profile allows use of the "scoped" variant of the
attribute (not a NameID XML structure).
Though above it seems the protocol is SAML2 so it's still wrong.

(Unless SSP has code checking for the SAML protocol version that just
means correct SAML1-usage of that specific attribute name might still
trigger the "must be a NameID" exception, even though that wouldn't be
correct. But let's forget about all that historic stuff.)

-peter

Tom Scavo

unread,
May 24, 2018, 9:56:50 AM5/24/18
to simpleSAMLphp
On Thu, May 24, 2018 at 9:51 AM, Peter Schober
<peter....@univie.ac.at> wrote:
>
> But let's forget about all that historic stuff.

As George Santayana once said: "Those who cannot remember the past are
condemned to repeat it." [1]

:-)

Tom

[1] https://en.wikiquote.org/wiki/George_Santayana

Peter Schober

unread,
May 24, 2018, 10:00:37 AM5/24/18
to simpleSAMLphp
* Tom Scavo <trs...@gmail.com> [2018-05-24 15:56]:
> On Thu, May 24, 2018 at 9:51 AM, Peter Schober
> <peter....@univie.ac.at> wrote:
> >
> > But let's forget about all that historic stuff.
>
> As George Santayana once said: "Those who cannot remember the past are
> condemned to repeat it." [1]

Not with SAML1, though.

Also, I bet someone else said that before him but he couldn't remember
the past and so he had to repeat it. ;)

-peter

Jaime Perez Crespo

unread,
May 25, 2018, 3:35:30 AM5/25/18
to simple...@googlegroups.com
Hola José Alfonso!

No, this is a change introduced some time ago in the SAML2 library:

https://github.com/simplesamlphp/saml2/blob/master/src/SAML2/Assertion.php#L553-L569

Any value for eduPersonTargetedID that’s not a NameID is essentially illegal. When we introduced NameID objects that could be easily managed by end users, we started parsing ePTID values to create those objects, and then that means if a string is received, you get that exception. The right fix is to send eduPersonTargetedID as the standard mandates: as a NameID.

> PS. BTW, I've been unable to get SAML Tracer to run with Firefox 60.0.1
> on Mac Sierra OS.

It’s a known Firefox issue, previously only on Windows platforms, now unfortunately replicated to other platforms (it would be funny that they are spreading the bug instead of fixing it, if it weren’t for all the trouble that’s creating). Just right click inside the window and its contents will appear:

https://github.com/UNINETT/SAML-tracer/issues/48


Jaime Pérez
Uninett / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

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

Peter Schober

unread,
May 25, 2018, 4:32:52 AM5/25/18
to simple...@googlegroups.com
* Jaime Perez Crespo <jaime...@uninett.no> [2018-05-25 09:35]:
> Any value for eduPersonTargetedID that’s not a NameID is essentially
> illegal.

Essentially.

Always illegal in SAML2, sometimes in SAML1 (depending on exact
attribute name).

> The right fix is to send eduPersonTargetedID as the standard
> mandates: as a NameID.

That could mean doing one of two things (both technically correct):

Either to send a NameID as the attribute value of the
eduPersonTargetedID attribute
(Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10").

Or to follow https://saml2int.org/profile/0.2/#section7 (last sentence
in section 7) and send that same NameID in the SAML Assertion's
Subject, and not send any eduPersonTargetedID attributes at all.

But going forward it would be different yet again, as according to
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html we MUST
send a transient NameID (for logout) and use attributes exclusively.
Not eduPersonTargetedID attributes, though ;), but new ones:
https://wiki.oasis-open.org/security/SAMLSubjectIDAttr

-peter

José A. Accino

unread,
May 28, 2018, 5:01:06 AM5/28/18
to simple...@googlegroups.com
On 25/5/18 at 9:35, Jaime Perez Crespo wrote:

> Any value for eduPersonTargetedID that’s not a NameID is essentially
> illegal. When we introduced NameID objects that could be easily
> managed by end users, we started parsing ePTID values to create those
> objects, and then that means if a string is received, you get that
> exception. The right fix is to send eduPersonTargetedID as the
> standard mandates: as a NameID.

Well, that was the issue. Actually, there were some differences in
metadata between both testing SPs, but the exception problem with the
failing test persisted even after refreshing them to solve those
differences.

As you know, the adAS IdP we are using allows us to choose the attribute
name format (default, URN, OID) for each SP. After setting a new, fresh
test app we saw that the working SP was using the default "raw"
attribute name ("eduPersonTargetedID") while the failing one was using a
URN (but, of course, the same problem occurred changing to OID).

Anyway the relevant chunk was something as:

<saml:Attribute xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Name="urn:mace:dir:attribute-def:eduPersonTargetedID"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
FriendlyName="eduPersonTargetedID">
<saml:AttributeValue
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"

xsi:type="xs:string">ce7406d90c9ba64ef95a36ba5f098d45e7722b14</saml:AttributeValue>
</saml:Attribute>

I see that SimpleSAMLphp (through Assertion::parseAttributeValue()) is
checking for constants EPTI_URN_OID or EPTI_URN_MACE in the attribute
name and for this reason didn't fail with the raw one. (Curiously
enough, another test application -the Switch attribute viewer- protected
with Shibboleth 2.6.0 returns the ePTID value without complaining.)

In any case, the pressing issue of testing the IdP status is solved
changing to check for ePPN instead, but in the immediate term it seems
that adAS IdP will have to correct the syntax of ePTID values... and
we'll have to revise the use of this attribute as well.

Thanks to you all for your help, advices and links :-) !
JA.

Peter Schober

unread,
May 28, 2018, 5:09:25 AM5/28/18
to simple...@googlegroups.com
* José A. Accino <acc...@uma.es> [2018-05-28 11:01]:
> Anyway the relevant chunk was something as:
>
> <saml:Attribute xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> Name="urn:mace:dir:attribute-def:eduPersonTargetedID"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> FriendlyName="eduPersonTargetedID">
> <saml:AttributeValue
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xsi:type="xs:string">ce7406d90c9ba64ef95a36ba5f098d45e7722b14</saml:AttributeValue>
> </saml:Attribute>

As explained, that's invalid (even though some software may not choke
on it, which doesn't make it right, of course): An attribute by that
Name is only allowed when using the SAML1 protocol, and only if the
attribute value has the "Scope" XML-attribute. You fail both those
requirements.
Once you use the only attribute name for eduPersonTargetedId allowed
for use with SAML2 (the OID form) its value MUST be a NameID with
persistent as format.

All that simply serves as a reminder as to why the new OASIS SubjectID
Attribute Profiles were created -- the status quo is a mess!
(Not to mention includes possibe security issues, with persistent
NameIDs and eduPersonTargetedID being defined to be case-sensitive,
but with applications treating identifiers as case-insensitive that
creates the risk of collisions, a.k.a. someone else having access to
your data at a given services. Unless you've only ever used
case-insensitive values in the identifiers your IDP has been
generating, of course.)

Best regards,
-peter

Peter Schober

unread,
Jun 12, 2018, 10:40:48 AM6/12/18
to simple...@googlegroups.com
* Jaime Perez Crespo <jaime...@uninett.no> [2018-05-25 09:35]:
> > PS. BTW, I've been unable to get SAML Tracer to run with Firefox 60.0.1
> > on Mac Sierra OS.
>
> It’s a known Firefox issue, previously only on Windows platforms,
> now unfortunately replicated to other platforms (it would be funny
> that they are spreading the bug instead of fixing it, if it weren’t
> for all the trouble that’s creating). Just right click inside the
> window and its contents will appear:

I'll be damned. Reverting to 0.4 worked on some machines but I'd have
never thought of right-clicking into the window!

(I'm still on FF 60.0.1, according to the issue tracker 60.0.2 solves
this.)


Thanks!

-peter

Thijs Kinkhorst

unread,
Jun 12, 2018, 1:18:18 PM6/12/18
to simple...@googlegroups.com
Op 12-06-18 om 16:40 schreef Peter Schober:
> I'll be damned. Reverting to 0.4 worked on some machines but I'd have
> never thought of right-clicking into the window!
>
> (I'm still on FF 60.0.1, according to the issue tracker 60.0.2 solves
> this.)

At least for Linux 60.0.2 does not solve it, and I think the relevant
bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1425829 which is
still open.


Thijs

Peter Schober

unread,
Jun 12, 2018, 2:17:27 PM6/12/18
to simple...@googlegroups.com
* Thijs Kinkhorst <thijs.k...@surfnet.nl> [2018-06-12 19:18]:
Hooray for right-click, then. ;)

Thanks for checking and the bug reference,
-peter

Garry Booth

unread,
Jun 13, 2018, 2:37:44 AM6/13/18
to simple...@googlegroups.com
Hi

Fyi, the problem persists on Firefox 60.0.2 for OSX as well, but seems to work on Windows 10 with FF 60.0.2

regards
Garry

Reply all
Reply to author
Forward
0 new messages