Adding forced password reset?
cab at umn.edu
Thu Apr 17 14:15:17 EDT 2014
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...
More information about the users