Adding forced password reset?

[Christopher Bongaarts]

On 4/17/2014 11:18 AM, Wessel, Keith wrote:
>
> I've been approached with the concept of sending users to our password 
> reset page after a successful Shib authentication if their password is 
> too old.
>
> The first thing that came to mind was the code in place at Wisconsin 
> for redirecting students to a Google Apps sign-up page if they try to 
> log into Google Apps without signing up first. I know this kind of 
> flow will be easier in V3, but that it's doable in V2.
>
> Is that going to be my best option? Or is there a better way to go? 
> Keep in mind that our password reset page is, in fact, 
> Shibboleth-protected. So, whatever I do would need to not stop the 
> user if the service requesting authentication was the password reset page.
>

We have a similar situation here; in our case, we were preserving 
existing functionality from our previous SSO system.

What we ended up doing was, when a user with an 
'expired-but-still-in-grace-period' password (based on an LDAP 
attribute) successfully logs in, we establish an SSO session (using a 
cookie), but flag it as being for an expired password.  Then we check to 
see if the SP is our password change application's entityID.  If it is, 
the user is allowed through.  If not, the IdP presents them with a page 
that says "you gotta go change yer password" with a link (button) to the 
password change page.  When the password change page sends them back to 
the IdP for authentication, the SSO session kicks in, sees that the user 
has an expired password but the application is now the password change 
app, and lets them through.

The SSO session is no good for any other SP, only the password change 
app, so there's no getting around it.

When a user changes their password successfully, the password change 
page sets a domain cookie that the IdP can read later.  It's essentially 
the same as the IdP's own SSO cookie, and if the IdP is able to decode 
it successfully, it sets a "real" SSO cookie and logs the user in (now 
at the normal, non-expired auth level).  This avoids the need to have 
the user re-enter their password immediately after setting it (really? 
you need my password a *third* time in two screens?).

The major downside to this approach is that typically the user will 
encounter this situation when attempting to access another SP (e.g. our 
course mgmt system).  When the password change app authenticates the 
user (by sending them back to the same IdP), it overwrites the 
LoginContext from the previous SP.  Without that context, there is no 
way to return the user to the original SP - you end up with a dead end 
page that says "now try logging in to the original app". You can search 
the list archives for when I asked about whether there was some way to 
"stack" LoginContexts to work around this problem.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140417/c3a0d7e2/attachment-0001.html