AW: PersistentId / principalName

[Ortner Nikolaus]

> Hm, now I think I understand Scott's remark in that context: That
> assumes that you changed the netid but the account still has the same
> "localId", thereby the IdP knows it's the same person? Then keying the
> persistentId only from the attribute used as localId would be enough
> and there's no need to ever look at the principalName or update
> anything in the DB?

Well - that's how the StoredIDDataConnector does it. And this works if the localId is applicable for this job (persistent, never reassigned,...).

But the other way around (mapping a persistentId to a principalName/username/netid/accountname and then use this principalName to resolve the user's attributes) gets messed up if I don't update the user's principalName in the database in case it has changed (StoredIDPrincipalConnector).

As I not yet have implemented the update of the DB-entries, this is why I can generate a persistent eduPersonTargetedID, but not yet a persistent SAML2StringNameID.

Regards,
	Nikolaus Ortner