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
|