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