SSO session & password change

[Matthew Slowe]

On 2021-07-29 00:18, IAM David Bantz wrote:
> I’m being asked to detect and act on changes in the status of directory 
> records. [We currently provide a way for accounts that fail normal LDAP 
> authentication because the account has expired to access specific 
> services; are about to deploy a new “lock” directory attribute to stop 
> an otherwise valid SSO session being used to access additional SPs.]
> 
> Next up is a request to detect a directory password change after the SSO 
> session was created and require the user to re-authenticate even if they 
> could otherwise use an existing valid SSO session. Stated use case is a 
> user who suspects their account is compromised and changes the password 
> so as to prevent misuse. It seems possible in principle to compete the 
> times in the AD attribute pwdLastSet with the SSO’s getCreationInstant, 
> but I’m unclear how to force re-authentication.
> 
> Are others invoking something like this function? It seems to impose 
> inconvenience on normal password change events and add significant 
> overhead for a very small number of uses. Is there a better approach? Is 
> it to be avoided for other reasons?

In a previous role where we had SimpleSAMLphp at the core of our SSO 
ecosystem, I had a similar requirement (pitted against the "we want to 
make sessions a lot longer" desire from management attempting to make 
the user experience better).

I extended SimpleSAMLphp's "sessionhousekeeping" cron job (which 
enumerated all of the sessions in memcache to check they existed, were 
valid and were in sync) to also do an  LDAP (Sun/Oracle Directory 
Server) search against each user to check if the object was locked [had 
nsAccountLock=true] OR had a recent password change [passwordLastChanged 
"since" last check].

This didn't extend the housekeeping job by too much as the user lookup 
was nice and fast (indexed search) and we used the LDAP filter to only 
return a result if we needed to care (which, mostly, we didn't) -- 
something akin to:

(&(uid=username)(|(nsAccountLock=true)(passwordLastSet>=20210729T093000Z))

If this matched then we'd invalidate the SSO session.

This was coupled with "short" SP session lifetimes on high-value 
services (where it didn't interfere with application session management) 
to mop up the "possibly compromised account" reason for a password 
change. SP session life is, after all, a risk management decision

I haven't the foggiest idea where to start doing this with Shibboleth 
right now, but the pattern worked and was well received by management 
and I don't recall getting any complaints about it.

Hope that helps,
-- 
Matthew Slowe (GPG: 0x6BE0CF7D04600314)
Senior Technical Consultant and Support specialist, Jisc
Team: 0300 300 2212, option 2
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4219 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20210729/04f032be/attachment.p7s>