<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/17/2014 11:18 AM, Wessel, Keith
wrote:<br>
</div>
<blockquote
cite="mid:A1EB7EC659FA0F429A55865D5820006D2DFB4B19@CHIMBX1.ad.uillinois.edu"
type="cite">
<p class="MsoNormal">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.<o:p></o:p><o:p> </o:p>
</p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<o:p> </o:p></blockquote>
<br>
We have a similar situation here; in our case, we were preserving
existing functionality from our previous SSO system.<br>
<br>
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.<br>
<br>
The SSO session is no good for any other SP, only the password
change app, so there's no getting around it.<br>
<br>
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?).<br>
<br>
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.<br>
<br>
<pre class="moz-signature" cols="72">--
%% Christopher A. Bongaarts %% <a class="moz-txt-link-abbreviated" href="mailto:cab@umn.edu">cab@umn.edu</a> %%
%% OIT - Identity Management %% <a class="moz-txt-link-freetext" href="http://umn.edu/~cab">http://umn.edu/~cab</a> %%
%% University of Minnesota %% +1 (612) 625-1809 %%
</pre>
</body>
</html>