EPPN and eduPersonTargetedID

[Ken Weiss]

Hi,

I'm not sure if this is a question for this list or not. If I'm in the
wrong place, please direct me to the right place...

We have several applications sitting behind Shibboleth SPs that rely on
the EPPN to uniquely identify a user. One of the IDPs with which we
integrate just told me that they use the authenticated user's email
address as the EPPN. Because email addresses change frequently, so do the
EPPNs in this IDP. The IDP manager did mention, though, that they also use
the eduPersonTargetedID attribute, and that one is guaranteed to be both
unique and stable.

Is the eduPersonTargetedID at least as widely used as the EPPN? Is the
eduPersonTargetedID always guaranteed to be unique and stable? I know
eduPersonTargetedID is not part of the standard Research and Scholarship
category attribute set, so I'm somewhat hesitant to change our application
to rely on that, instead of EPPN.

Maybe what I really want to ask is this: What attribute do you recommend
using as a unique identifier for a Shibboleth-authenticated user?

--Ken

------------------------------------------------------------
Ken Weiss ken.weiss-E+***@public.gmane.org
UC Office of the President 510-587-6311 (office)
California Digital Library 916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612

[David Bantz]

" ePPN looks like an email address but is not intended to be a person's published email address or be used as an email address. In general, name-based identifiers tend to be subject to some degree of expected change and/or reassignment,” so arguably the practice of changing ePPN when a user changes email address is less than best practice.
https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-eduperson-201203.html#eduPersonPrincipalName

ePTID is defined as “persistent” ~ "SHOULD be maintained...long enough to be useful as a key for consuming services.”
https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-eduperson-201203.html#eduPersonTargetedID

ePTID is opaque and not necessarily human-friendly. You mention “several applications [and] SPs”; if you hope for correlation of identities between these applications, ePTID may not be what
you want as the value will likely be different for different SPs.

Post by Ken Weiss
Hi,
I'm not sure if this is a question for this list or not. If I'm in the
wrong place, please direct me to the right place...
We have several applications sitting behind Shibboleth SPs that rely on
the EPPN to uniquely identify a user. One of the IDPs with which we
integrate just told me that they use the authenticated user's email
address as the EPPN. Because email addresses change frequently, so do the
EPPNs in this IDP. The IDP manager did mention, though, that they also use
the eduPersonTargetedID attribute, and that one is guaranteed to be both
unique and stable.
Is the eduPersonTargetedID at least as widely used as the EPPN? Is the
eduPersonTargetedID always guaranteed to be unique and stable? I know
eduPersonTargetedID is not part of the standard Research and Scholarship
category attribute set, so I'm somewhat hesitant to change our application
to rely on that, instead of EPPN.
Maybe what I really want to ask is this: What attribute do you recommend
using as a unique identifier for a Shibboleth-authenticated user?
--Ken
------------------------------------------------------------
UC Office of the President 510-587-6311 (office)
California Digital Library 916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612
--

[Tom Scavo]

Post by Ken Weiss
Is the eduPersonTargetedID at least as widely used as the EPPN?

(The following answer is based on the 95 IdPs that support R&S.)

No, roughly 50% of IdPs will assert ePTID while virtually all IdPs are
capable of asserting ePPN. (Whether or not they are *willing* to
release ePPN is another question altogether.)

Post by Ken Weiss
Is the eduPersonTargetedID always guaranteed to be unique and stable?

The value of ePTID together with the IdP entityID is globally unique.
If by "stable" you mean "unlikely to change," the answer is yes (but
there is no guarantee that ePTID will persistent indefinitely). More
importantly, ePTID is guaranteed to be non-reassigned.

Post by Ken Weiss
I know
eduPersonTargetedID is not part of the standard Research and Scholarship
category attribute set, so I'm somewhat hesitant to change our application
to rely on that, instead of EPPN.

Well, ePTID is included in the R&S attribute bundle but IdPs are not
required to assert it unless their ePPN may be reassigned. (Btw, 75%
of the R&S IdPs assert ePPN that is not reassigned.)

Post by Ken Weiss
Maybe what I really want to ask is this: What attribute do you recommend
using as a unique identifier for a Shibboleth-authenticated user?

There's is no one right answer. For the apps we run here, we require
ePPN. To protect ourselves against reassignment (which is important in
our case), we bind the ePPN to the user's mobile device.

Hope this helps,

Tom

[Eric Goodman]

Post by Tom Scavo

Post by Ken Weiss
Is the eduPersonTargetedID always guaranteed to be unique and stable?

The value of ePTID together with the IdP entityID is globally unique.
If by "stable" you mean "unlikely to change," the answer is yes (but
there is no guarantee that ePTID will persistent indefinitely). More
importantly, ePTID is guaranteed to be non-reassigned.

Within the UC System, I know that at least some of the IdPs generate ePTIDs based on a dynamic hash of some attribute and the SP name. What that means is that if the "some attribute" changes then the presumption of persistence -- and possibly non-reassignability -- is lost.

Basically, I'm saying that Tom gave you the standards-based answer; the pragmatic answer might be subtly different.

I recognize that your questions may be targeted at a broader net than just UC, but I'm guessing that we're at least some of your customers of concern. :) I do periodically survey UC locations to get answers to operational questions like these (independent of what the standard claims to require). I don't think I've ever done such a survey on the ePTID attribute in particular, but I can if that would be useful.

[For longtime readers, this post is basically my ongoing "ForceAuthn issues" commentary translated to ePTID values... :)]

--- Eric

[Cantor, Scott]

Post by Eric Goodman
Within the UC System, I know that at least some of the IdPs generate
ePTIDs based on a dynamic hash of some attribute and the SP name. What
that means is that if the "some attribute" changes then the presumption
of persistence -- and possibly non-reassignability -- is lost.

If you violate non-reassignment, you are grossly violating the standard.
That should not be something SPs give any consideration to in their
designs, particularly given that most of them don't even address the fact
that EPPN doesn't have this property.

Post by Eric Goodman
[For longtime readers, this post is basically my ongoing "ForceAuthn
issues" commentary translated to ePTID values... :)]

There's no gray here though, the spec is 100% clear and explicit on it.
This is why supporting persistent IDs is a very deliberate decision and is
not an out of the box feature, and thus also much less widely deployed
than simpler username attributes.

-- Scott

[Eric Goodman]

Fair enough on all points.

May still merit a survey though... :)

--- Eric

-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Friday, August 29, 2014 4:40 PM
To: Shib Users
Subject: Re: EPPN and eduPersonTargetedID

Post by Eric Goodman
Within the UC System, I know that at least some of the IdPs generate
ePTIDs based on a dynamic hash of some attribute and the SP name. What
that means is that if the "some attribute" changes then the presumption
of persistence -- and possibly non-reassignability -- is lost.

If you violate non-reassignment, you are grossly violating the standard.
That should not be something SPs give any consideration to in their designs, particularly given that most of them don't even address the fact that EPPN doesn't have this property.

Post by Eric Goodman
[For longtime readers, this post is basically my ongoing "ForceAuthn
issues" commentary translated to ePTID values... :)]

There's no gray here though, the spec is 100% clear and explicit on it.
This is why supporting persistent IDs is a very deliberate decision and is not an out of the box feature, and thus also much less widely deployed than simpler username attributes.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Ken Weiss]

As usual, some really great responses from the community. Thanks!

1) Tom Scavo said, "To protect ourselves against reassignment (which is
important in our case), we bind the ePPN to the user's mobile device." I
assume by 'mobile device' you mean a single-use password token, like a
SecurID? You're not talking about a phone, are you? And, since you are
concerned about reassignment, I assume you must be using EPPN as a key for
something. What do you do when an individual's EPPN changes? Do you
consider them a new user? Do you make any effort to re-associate them with
data stored under their previous EPPN? If so, how do you connect the old
identity to the new one?

2) Eric Goodman: Yes, I encountered this issue within the UC system. UC
Merced's IDP returns the authenticated user's email address as the EPPN.
So, whenever the email address changes, so does the EPPN. Our application
stores datasets for the user, and (currently) uses the EPPN as the primary
key to associate users with their datasets. So if the EPPN changes, any
datasets stored under the old EPPN will become orphans. John Kamminga at
Merced offered the EPTID as a persistent alternative, but as far as I
know, Merced is the only campus that delivers EPTID. I do think that some
coordination among the UC IDPs would be useful here, and your survey is
probably a good idea. I don't expect to arrive at an attribute that
identifies an individual if they move from one campus to another, but it
would be nice to have a single attribute we can all rely on to remain
consistent and unique as long as the individual remains at a given campus.
If that value can be persistent across multiple stints at the same campus,
that would be even better.

Those last two sentences apply more generally than just within the
University of California system. It would be nice if every institution
that's part of the InCommon federation agreed on an identifying attribute
and assured that the value for that attribute would be stable for the
duration of an individual's association with the institution and never
re-assigned to a different individual. I thought that was EPPN, but
clearly, I thought wrong.

--Ken




------------------------------------------------------------
Ken Weiss ken.weiss-E+***@public.gmane.org
UC Office of the President 510-587-6311 (office)
California Digital Library 916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612

Post by Eric Goodman
Fair enough on all points.
May still merit a survey though... :)
--- Eric
-----Original Message-----
On Behalf Of Cantor, Scott
Sent: Friday, August 29, 2014 4:40 PM
To: Shib Users
Subject: Re: EPPN and eduPersonTargetedID

Post by Eric Goodman
Within the UC System, I know that at least some of the IdPs generate
ePTIDs based on a dynamic hash of some attribute and the SP name. What
that means is that if the "some attribute" changes then the presumption
of persistence -- and possibly non-reassignability -- is lost.

If you violate non-reassignment, you are grossly violating the standard.
That should not be something SPs give any consideration to in their
designs, particularly given that most of them don't even address the fact
that EPPN doesn't have this property.

Post by Eric Goodman
[For longtime readers, this post is basically my ongoing "ForceAuthn
issues" commentary translated to ePTID values... :)]

There's no gray here though, the spec is 100% clear and explicit on it.
This is why supporting persistent IDs is a very deliberate decision and
is not an out of the box feature, and thus also much less widely deployed
than simpler username attributes.
-- Scott
--
To unsubscribe from this list send an email to
--
To unsubscribe from this list send an email to

[David Bantz]

http://macedir.org/specs/eduperson/#eduPersonUniqueId

Post by Ken Weiss
It would be nice if every institution
that's part of the InCommon federation agreed on an identifying attribute
and assured that the value for that attribute would be stable for the
duration of an individual's association with the institution and never
re-assigned to a different individual. I thought that was EPPN, but
clearly, I thought wrong.

[Tom Scavo]

(I'll keep my responses brief since this is mostly off-topic. Ken, you
can contact me offline for more info.)

Post by Ken Weiss
1) Tom Scavo said, "To protect ourselves against reassignment (which is
important in our case), we bind the ePPN to the user's mobile device." I
assume by 'mobile device' you mean a single-use password token, like a
SecurID? You're not talking about a phone, are you?

Yes, Duo Mobile (which is a native app) running on a smartphone.

Post by Ken Weiss
And, since you are concerned about reassignment

All but the simplest apps should be concerned about reassignment ;-)

Post by Ken Weiss
I assume you must be using EPPN as a key for something.

Not sure how to answer that...ePPN is a globally unique identifier for
a federated user, so we bind ePPN to a local identity, and then bind
it again to the user's mobile device.

Post by Ken Weiss
What do you do when an individual's EPPN changes? Do you
consider them a new user?

Yes. If and when the ePPN is reassigned, MFA is broken, so the user
can't log in anymore. At that point, the user starts from scratch.

Post by Ken Weiss
Do you make any effort to re-associate them with
data stored under their previous EPPN?

Nothing is lost if the user has to start from scratch (except some of
the user's time).

Post by Ken Weiss
If so, how do you connect the old identity to the new one?

There is only one local identity. Today it is bound this ePPN,
tomorrow it's bound to some other ePPN. Nothing is lost.

Our app is more like a typical vendor SaaS app. The customer tells the
vendor who gets access to the app. It's up to the vendor to make sure
only those users get access, nobody else.

Hope this helps,

Tom

[Tom Scavo]

(again off-topic...you can shift this over to the InC participant's
list if you want)

Post by Ken Weiss
It would be nice if every institution
that's part of the InCommon federation agreed on an identifying attribute

Like it or not, that attribute is ePPN, which I believe is supported
by almost all IdPs. The eduPersonTargetedID attribute is supported by
less than half of the IdPs (based on incomplete data cited earlier).
The eduPersonUniqueId attribute is new and virtually non-existent.

Post by Ken Weiss
and assured that the value for that attribute would be stable for the
duration of an individual's association with the institution and never
re-assigned to a different individual.

That's a tall order but note that stability and non-reassignability
are independent characteristics.

Post by Ken Weiss
I thought that was EPPN, but clearly, I thought wrong.

It is what it is, I'm afraid. ePPN is universally supported so it
makes sense to build an app around that assumption. Of the two
characteristics you mentioned, non-reassignability is critical (for
some apps) so in that case you have to workaround it.

Tom

[Michael Hodges]

#It is what it is, I'm afraid. ePPN is universally supported so it
#makes sense to build an app around that assumption. Of the two
#characteristics you mentioned, non-reassignability is critical (for
#some apps) so in that case you have to workaround it.

We can ensure that ePPN is never reassigned, but we can't ensure that
it is not occasionally changed (for example when a person has two
and we consolidate). For those apps that require it, we recommend
that they listen to our message broker for events that indicate an ePPN
change.

- Michael

Michael Hodges
Enterprise Middleware, Identity and Access Management
University of Hawaii, Information Technology Services
michael.hodges-***@public.gmane.org
808-956-7195 (GMT -10:00)

Post by Tom Scavo
(again off-topic...you can shift this over to the InC participant's
list if you want)

Post by Ken Weiss
It would be nice if every institution
that's part of the InCommon federation agreed on an identifying attribute

Like it or not, that attribute is ePPN, which I believe is supported
by almost all IdPs. The eduPersonTargetedID attribute is supported by
less than half of the IdPs (based on incomplete data cited earlier).
The eduPersonUniqueId attribute is new and virtually non-existent.

Post by Ken Weiss
and assured that the value for that attribute would be stable for the
duration of an individual's association with the institution and never
re-assigned to a different individual.

That's a tall order but note that stability and non-reassignability
are independent characteristics.

Post by Ken Weiss
I thought that was EPPN, but clearly, I thought wrong.

It is what it is, I'm afraid. ePPN is universally supported so it
makes sense to build an app around that assumption. Of the two
characteristics you mentioned, non-reassignability is critical (for
some apps) so in that case you have to workaround it.
Tom
--
To unsubscribe from this list send an email to

[Cantor, Scott]

Post by Ken Weiss
Maybe what I really want to ask is this: What attribute do you recommend
using as a unique identifier for a Shibboleth-authenticated user?

As another response mentioned, if you have more than one SP entityID, a
SAML persistent NameID (*) is going to vary for each one. That alone may
render it useless to you as an identifier. There are ways around it, but
not ones you'll get random IdPs to work with you on.

One practice is to use the persistent ID to recognize that a given EPPN is
the same user as an earlier one by looking at and storing both, and noting
when EPPN changes but the persistent ID doesn't.

Lastly, there's an attribute I proposed, eduPersonPrincipalNamePrior, to
carry a list of older EPPNs for a person, to help identify changes. It's
also not widely supported, but is another way of handling change
identification in-band.

All of this is about changes of identifiers, while reassignment is in fact
a much bigger concern.

-- Scott

(*) eduPersonTargetedID in SAML is a Subject NameID with the "persistent"
Format. The attribute was just an eduPerson concept to represent it
abstractly.