Adding forced password reset?
David Langenberg
davel at uchicago.edu
Thu Apr 17 13:18:44 EDT 2014
On Thu, Apr 17, 2014 at 10:54 AM, Paul Hethmon <
paul.hethmon at clareitysecurity.com> wrote:
> On Apr 17, 2014, at 12:18 PM, Wessel, Keith <kwessel at illinois.edu> wrote:
>
> 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.
>
>
> 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.
>
*Kluge alert*
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.
Dave
--
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140417/51f086ba/attachment.html
More information about the users
mailing list