Hi John,
I remember reading about this when I set up our Shibboleth IdP but I can't now seem to find the reference so this is from memory.
The persistent id is designed to be unique on a per user and per SP basis so it can be used by SPs for personalisation (i.e. 'your account') but, because it varies with SP, two SPs cannot get together and combine information about you. It is also completely opaque so contains no identifiable information. This is different from, for example, using email address. It is not designed to control authentication in any way.
The purpose of deactivationDate is to deactivate *that specific* opaque identifier. This allows a user to wipe their account with an SP. The only information the SP gets (assuming you don't release other attributes) is this identifier so if that changes from abc123 to xzy456 then from the SP's point of view you are a different person - they have absolutely no way of knowing otherwise, unlike any other form of request to delete details/wipe account etc.
Because the storedID connector works on a per SP basis the deactivation can be done for just one SP with the user retaining state with all other SPs.
If you use the computedID connector then the only way to change persistent ID is to change the inputs. In practice this means changing username and this will cause IDs to change for all SPs so the user loses state with everybody (as well as having to have a new username which likely breaks all your local identity management anyway)
The different form of id created is that the first id is created in the same way as computedID for backwards compatibility but subsequent ones are created using a different (presumably more sensible?) algorithm.
So the storedID gives more flexibility than computedID. Having said that, since we installed it, no one has asked for their details to be revoked anywhere. The reason we went with it was the message that computedID was deprecated, not because we thought per SP revocation might be required.
Hope this helps
Jonathan
--
-------------------------------------------------------------------------------------
Jonathan Haynes
Senior Network Specialist
IT Department Tel: 01234 754205
Bld 63, e-mail: [log in to unmask]
Cranfield University,
Cranfield,
Beds, MK43 0AL
> -----Original Message-----
> From: Discussion list for Shibboleth developments [mailto:JISC-
> [log in to unmask]] On Behalf Of John Horne
> Sent: 21 February 2014 17:35
> To: [log in to unmask]
> Subject: persistentId - deactivationDate - is this right?
>
> Hello,
>
> I have been looking at the MySQL database we had set up for our site
> IdP, and the Shibboleth documentation on this. No problems so far.
>
> I tried playing with the 'DeactivationDate' field, i.e. gave it a value,
> and then used the UK Federation DS web page to see what attributes (if
> any) were being sent. With a DeactivationDate set, I expected our IdP to
> fail to authenticate me. Instead Shibboleth created me a new
> persistentId.
>
> From the idp-process log file, Shibboleth seems to have some builtin DB
> queries when using the StoredId dataconnector type. The log shows:
>
> =======================
> Checking for existing, active, stored ID for principal 'jhorne'
> Selecting active persistent ID entry based on prepared sql statement:
> SELECT * FROM shibpid WHERE localEntity = ? AND peerEntity = ? AND
> localId = ? AND deactivationDate IS NULL
> =======================
>
>
> Given that the deactivationDate is 'not null', this statement will
> return no data. However, Shibboleth then goes on:
>
> =======================
> No existing, active, stored ID, creating a new one for principal
> 'jhorne'
> ...
> Storing persistent ID entry based on prepared sql statement: INSERT INTO
> shibpid (localEntity, peerEntity, principalName, localId, persistentId,
> peerProvidedId, creationDate) VALUES (?, ?, ?, ?, ?, ?, ?)
> =======================
>
>
> So having found no persistentId because of the deactiviationdate, it
> inserts a new record. Not only that, but the new persistentId looks
> nothing like the old one!
>
>
> Is that right? I would have thought that setting a deactivationdate was
> supposed to stop a user authenticating for a specific SP (the
> peerEntity)?
>
> I am still trying to determine why the new persistent is different from
> the old one.
>
>
>
>
>
> Thanks,
>
> John.
>
> --
> John Horne Tel: +44 (0)1752 587287
> Plymouth University, UK Fax: +44 (0)1752 587001
|
