<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 10:54 AM, Paul Hethmon <span dir="ltr"><<a href="mailto:paul.hethmon@clareitysecurity.com" target="_blank">paul.hethmon@clareitysecurity.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class="">
On Apr 17, 2014, at 12:18 PM, Wessel, Keith <<a href="mailto:kwessel@illinois.edu" target="_blank">kwessel@illinois.edu</a>> wrote:<br>
<div><br>
<blockquote type="cite">
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
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.<u></u><u></u></div>
<br>
</blockquote>
</div>
<div><br>
</div>
</div><div>Having the change password page behind SSO can leave a hole open to the forced password change. User logs in, gets Shib session, directed to change password. Simply ignores it and accesses their original target. Previous session handler sends them to the
original target. Just be aware it's a circumstance you have to allow for.</div></div></blockquote><div><br></div><div>*Kluge alert*</div><div><br></div><div>You could leverage the MCB's initialAuthContext in such a fashion as to establish a session and set a session flag indicating the only SP allowed is the password change app, then do the re-directs to that app. You'd also need to setup the <IDMS> attribute such that it could read the flag (hint: use a ScriptedAttribute) and if the password age is too old & EntityID of SP is not the password change app, deny all contexts. This should effectively cause a SAML AuthnFail message to all SPs except for the password change SP & meet the requirement. Granted, I'm probably missing some small detail that will make all this not work, but I think the concept is sound.</div>
<div><br></div><div>Dave</div><div><br></div></div><div><br></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div></div>