<div class="gmail_quote">On Fri, Jan 27, 2012 at 2:02 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 1/27/12 3:54 PM, "David Langenberg" <<a href="mailto:davel@uchicago.edu">davel@uchicago.edu</a>> wrote:<br>
<br>
>I've noticed recently that an increasing number of SPs around my campus<br>
>are requiring forceAuthn in an attempt to take back control of the<br>
>user-auth/logout workflow. The typical argument they make is "think of<br>
>the kiosk users". Yeah Yeah, we've all had these same arguments with<br>
>vendors & SP admins at our own institutions. However, being an IdP<br>
>admin and java developer who hates typing his password more than once per<br>
>day, I'd like to write some kind of extension or plugin which would<br>
>instruct the IdP to ignore any forceAuthn requests for a particular list<br>
>of users and just forge the response to make the SP think it got what it<br>
>asked for.<br>
<br>
</div>Actually you might produce an instructive result by just telling the truth<br>
and see if they notice. The SP generates forceAuthn easily, but verifying<br>
the result is not automatic because it doesn't rely on signed requests.<br>
You have to enforce a delta to allow since the authentication time, and my<br>
guess is they aren't.<br>
<br>
That aside, it seems like the best way to approach it is with a checkbox<br>
on the login page in a custom login handler to create long-lived session<br>
or not at the IdP. That accomodates kiosks without playing tricks.<br></blockquote><div><br></div><div>Yeah, the checkbox with cookie was one of my thoughts for generating the bypass-forceAuthn flag.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>Before i proceed to just blindly hack this into the IdP, I was wondering<br>
>if someone would give me a pointer of the best way to add this new<br>
>feature in a pluggable & maintainable way so I wouldn't need to keep a<br>
>set of diffs around.<br>
<br>
</div>You need a custom login handler to do anything with the IdP that isn't<br>
trivial and has good error behavior for users. I can't imagine any better<br>
way to do what you're asking. There are no hooks into the forceAuthn flow<br>
other than the login handler. If you tell the IdP your handler supports<br>
forceAuthn, then that becomes a metter for the login handler to deal with.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Excellent, thanks Scott.</div><div><br>Dave</div><div><br></div></div>-- <br>David Langenberg<div>Identity Management</div><div>
The University of Chicago</div><br>