Print

---

Andy Swiffin wrote:

> The Identity Provider Deployment document from the "Federation" site
> says:
> 
> "eduPersonTargetedID.  this attribute provides a consistent, opaque
> pseudonym for the user that is different for each service provider"
> 
> How does that work?    I would imagine we hash the userID and store
> that away in a directory attribute which is made available to the IdP
> but that is just one value, if it is different when delivered to each SP
> who makes it different?

The example implementation of eduPersonTargetedID that is provided with
current versions of the Shibboleth IdP operates by hashing together:

	the user ID

	the SP's entity name

	a secret

The advantage of this approach is that there is no need to store
additional information.  It has numerous disadvantages, though, and as a
result many sites will end up doing something that involves storing data
somewhere.

> Responding to what Karen said - we are one of the majority of
> institutions that do re-use user IDs, so could not sign up to the
> non-reassigned clause.

Not true.  The requirement not to reassign the same ePTI to different
people can be met by any technical means you choose.  If you reassign
user IDs, you clearly can't rely on the simple technical means provided
by the example plug-in provided in the IdP distribution; you'll have to
do something else.  So the reuse of user IDs does not rule out being
able to assert user accountability for federation purposes, you just
have to work harder.

>  But, could we not attach, for example, a year
> indicator to the userID thus making it unique and then hash that and
> store it in the eduPersonTargetedID attribute?  So for example should I
> leave Dundee and another alswiffin turn up a couple of years later, even
> though their local login ID would be the same, i.e. alswiffin,  for the
> purposes of eduPersonTargetedID I would have been a hashed alswiffin2007
> and they would be a hashed alswiffin2009 hence unique.   

If you have an attribute store that includes both a local principal name
and a year-qualified principal name then you can use the year-qualified
version to feed into your eduPersonTargetedID calculations and you've
met the non-reassignment criteria for ePTI.

It is in fact possible to configure the Shibboleth IdP to use the
example ePTI plug-in and have it take the "user ID" component from any
subject attribute, so this wouldn't really be much work (other than
populating the qualified principal name attribute).

You might still want to look at actually storing ePTI values for each
principal/SP combination to allow for things like disassociating a user
if they think one of the SPs has compromised their privacy, but that's a
separate question.

	-- Ian