Adding forced password reset?

[Wessel, Keith]

Thank you all for the suggestions and input on this. Sounds like there are a few ways to pull it off, and the MCB that we'll be putting into production soon will add even more options.

Chris, any chance you're willing to share with us specifics on your implementation either on or off-list? It's almost identical to what we want to do.

Thanks,
Keith


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Christopher Bongaarts
Sent: Thursday, April 17, 2014 1:15 PM
To: users at shibboleth.net
Subject: Re: Adding forced password reset?

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<mailto: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/20140418/d8fc4b8e/attachment.html