<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Keith<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> users-bounces@shibboleth.net [mailto:users-bounces@shibboleth.net]
<b>On Behalf Of </b>Christopher Bongaarts<br>
<b>Sent:</b> Thursday, April 17, 2014 1:15 PM<br>
<b>To:</b> users@shibboleth.net<br>
<b>Subject:</b> Re: Adding forced password reset?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 4/17/2014 11:18 AM, Wessel, Keith wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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>
</blockquote>
<p class="MsoNormal"><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>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>%% Christopher A. Bongaarts %% <a href="mailto:cab@umn.edu">cab@umn.edu</a> %%<o:p></o:p></pre>
<pre>%% OIT - Identity Management %% <a href="http://umn.edu/~cab">http://umn.edu/~cab</a> %%<o:p></o:p></pre>
<pre>%% University of Minnesota %% +1 (612) 625-1809 %%<o:p></o:p></pre>
</div>
</body>
</html>