Hi John,
It's not obvious from that documentation, but I think that
deactivationDate is a mechanism for revoking a persistent ID. The
deactivationDate is the date at which the persistent ID should be
revoked. So, I don't know what date you set, but if it was today's date
or earlier, presumably it revoked the old persistent ID and gave you a
new one.
The new one is different from the old one because (as it says on the
ResolverStoredIDDataConnector page) "Every subsequently generated ID for
a given user/IdP/SP triple, if the first one is revoked, is a Type 4 UUID."
Does that make sense?
Cheers,
Sara
UK federation
On 21/02/2014 17:34, John Horne wrote:
> 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.
>
--
Sara Hopkins
Support Team
UK Access Management Federation for Education and Research
web: http://www.ukfederation.org.uk/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
|