Sara et al.,
A short follow-up to the recent StoredID discussion:
* Sara Hopkins <[log in to unmask]> [2014-02-21 18:21]:
> On 21/02/2014 15:56, Peter Schober wrote:
> >The IDP's entityID is stored as well, I think (don't have an IDP at
> >hand atm):
> >https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverStoredIDDataConnector
> >This seems to allow the IDP to send the previously used NameQualifier,
> >resulting in the same complete NameID at the SP, even if the IDP's
> >entityID changed.
>
> Oh, is it? Is that the localEntity field?
I tried to verify this but the IDP will still write the current
entityID into the NameQualifier attribute of any issued NameIDs.
(I.e., it looks for an existing record using its current entityID,
fails and generates a new record, with changed localEntity and
persistentId.)
So StoredID does not protect you against a changed IDP entityID so
easily. You do still have the existing persistentId values, though,
so you could update the localEntity column of all existing records in
the DB to the current entityID, and coordinate batch updates with
relevant SPs to reflect the IDP part of the NameID 3-tuple having
changed. (The user-specific part will remain the same for all
subjects, so such an update would be rather simple: replace all
occurances of "old-idp.example.ac.uk" with "new-idp.example.ac.uk").
Certainly more involved that I would have hoped for, sorry.
My personal reason for using StoredID remains being able to accomodate
for changed/changing userids (not so much entityIDs). Even if you have
a practice or policy of not doing that (as we do) it still might
happen when sufficiently important people nag people sufficiently high
up in the hierarchy. Then you just update the DB with the changed
username and move on.
Best regards,
-peter
|