storedID and IDP entityID changes

[Cantor, Scott]

On 2/25/14, 8:46 AM, "Peter Schober" <peter.schober at univie.ac.at> wrote:

>From a recent discussion about what kind of changes (user principal,
>SP entityID, IDP entityID?) the StoredID approach helps to protect
>you, compared to ComputedIDs:

It's primarily about the ability to roll over the identifier, and to
reverse them, not the change entityIDs without a problem. It's not even
clear what changing one means, since technically that does change the
identifier. There could be scenarios where the IDs (whether the value or
the NameQualifier) should change and some not.

>When changing the IDPs entityID (for whatever reason, obviously it
>should never) the current StoredID implementation will issue the
>current entityID as NameQualifier value, though the previously
>generated one would be available in the RDBMS.
>(The IDP looks for an existing persistentID matching its own entityID
>as localEntity and will generate a new one otherwise.)

I would imagine maybe that should be an option.

>Would it make sense to have the IDP use the stored localEntity instead
>in issued NameIDs? Necessarily the assertions Issuer wouldn't match
>the NameQualifier value then. Not sure if this will break stuff.

It will/can, yes. The more recent SPs do enforce that in a filter rule by
default, though of course you can manipulate it.

>If the IDP does not use the RDBMS abstraction layer for NameQualifier
>values why does it store its own entityID as localEntity then? To
>allow sharing of a single table in a single database on a single
>server across several IDPs? (That's fully possible with that design,
>I'm just asking whether that's an intended feature. Obviously that is
>mutually exclusive with the change I'm asking above.)

Don't recall that being discussed, but the idea of virtualizing IdPs
certainly has come up historically.

-- Scott