PersistentId / principalName

[Cantor, Scott]

On 7/4/12 5:25 AM, "Ortner Nikolaus" <N.Ortner at fh-kaernten.at> wrote:
>
>I run a Shibboleth IdP (2.3.8) with a DataConnector xsi:type="StoredId"
>using a sourceAttributeID other than the requestContext.principalName.
>Works fine, but I'm a bit concerned about changing or reusing user's
>principalName (which may occur occasionally).

PersistentIDs are (and in fact MUST be) totally divorced from any
name-based identifier for a user. If something breaks when a username
changes, your deployment needs to be adjusted. I can't imagine that the
connector in question has any issue with this.

>I propose the StoredIDDataConnector.getStoredId() should update the
>principalName in case it has changed (and the principalName is not used
>as the localId).

The database should be mapping the IDs to a stable, likely opaque
identifier that should never change or be reassigned. That's just basic
IDM. You really shouldn't, and cannot, support persistent IDs if you don't
have such an underlying value to base the deployment on. I don't have that
myself, so my IdP still doesn't support them.

Maybe I'm totally lost and you're identifying a bug here, but without
looking at the code, this all sounds pretty fishy to me.

I'm more familiar with the mechanics of the hashing approach, which
definitely is vulnerable to all sorts of issues if you make a choice as
bad as to seed the hash with a name-based identifier, let alone when you
might reassign. I wouldn't be surprised if the database version would have
similar issues.

-- Scott