AW: PersistentId / principalName

[Ortner Nikolaus]

Hi,

> If you are changing people's organizational identifier than you will
> also need to update the table.  The IdP has to be able to remap the
> persistent ID back to the ID of the user that it belongs to so that it
> can then proceed to further process requests like attribute queries.

Yes, that's the point - my question is if it's ok just to update the entries and let things happen. Or am I running into side-effects then? - caching-things, or other problems (e.g. the user that has to be renamed has an active session).


> You can file a request in the issue tracker if you want.  I will state
> now that I find the notion that the IdP should somehow guess that your
> IDM has given an account a new unique key (and possibly reassigned the
> old one) to be highly suspect.

Sure, a blind update may not be ideal - maybe the IdP's StoredIDDataConnector should rise some kind of alert if the stored principalName shows a discrepance from the principalName given by the login-context.
Just in case either the resolving of the user's localId was wrong or someone forgot to update the principalName in the database.

Kind regards,
	Nikolaus Ortner