Modify forceAuthn Authentication Engine Behavior

[Chad La Joie]

No, I understand what you're asking for, but it's *not* a software issue.

If the service has a session, then the user is in trouble if they just
walk away from the session.  You can shorten the session, as you've
done, but that doesn't remove the issue it just makes the attack
window smaller.

Now, that said, Peter did submit a feature request that would allow
the IdP to adjust its session lifetime based on criteria as a way to
deal with the kiosks.  That can't really be done in v2 but support for
things like that is scheduled in v3 (and so far it looks like that's
working out).  The result would be a narrowed attack window.

But again, the only actual solution is to either require
authentication for every single request or educate the user so they
don't do dumb things.

On Thu, Dec 15, 2011 at 16:58, John Mitchell <jpmitchell at alaska.edu> wrote:
> Chad,
>
> On 12/15/2011 12:40 PM, Chad La Joie wrote:
>> If applications care about sessions, then forceAuthn is what they need.
>>
>> If, instead, the issue is that people are logging in and then walking
>> away and leaving their sessions, then it's not a software issue.
>> Unless your apps are authenticating users with every single request
>> made by the browser, then they have this issue.
>>
>
>    Ah. I think we are cross talking here. Sorry about that I tend to do
> that. Jump to the middle somewhere. Anyway, here is the scenario. The
> application has a short session interval and logs the user off
> automatically when there is no activity. It is served to the user via a
> shared kiosk and different people will be using it frequently. So the
> IdP session will be too long and will need to be destroyed somehow, I
> dont want to scale back the IdP session length as then it will impact my
> whole user base and not just this applications user base. I have built
> but not deployed a hook for applications to call a logout on the IdP and
> then on the SP but its fragile and is a layered redirect mess to get the
> user back to the app. It also requires the user to push the logout
> button. I think what I really need as a way for the application to
> switch users so to speak and to have a say in the IdP session length
> (not that I like that mind you). The only way I could see to do that was
> to somehow selectively disable SSO and remove the IdP session. When I
> first looked at this, forceAuthn looked like the solution but it
> requires the same user login. So then we where back to close the browser
> on the kiosk, but the application owner did not accept that and I guess
> it also posses issues for the way the kiosk is setup security wise. I
> thought maybe another way to skin this cat would be for the SP to assert
> a authnContextClassRef attribute and have a login handler that does not
> do SSO for that, but then I run into the session problem again right? So
> the login handler would have to trash the session. So I turned to the
> simplest solution which was to change the behavior of forceAuth and then
> setup the SP with a very short session length and have it always assert
> forceAuthn. Then the application can do its own short session/SSO
> management.
>
>> On Thu, Dec 15, 2011 at 16:29, John Mitchell <jpmitchell at alaska.edu> wrote:
>>> On 12/15/2011 12:15 PM, Chad La Joie wrote:
>>>> Right, it will check to make sure it's the person who owns the session.
>>>>
>>>> So, how do you deal with this for any other application?  People
>>>> walking away and leaving sessions lying around isn't an IdP issue.
>>>>
>>>   Currently this is the first application that we have integrated that
>>> had these requirements and sadly we started down the Shib integration
>>> route without knowing it was a kiosk app. We have had other applications
>>> with this requirement and they have opted to not use Shibboleth in favor
>>> of other solutions (which was bad for the project).
>>>   Generally to speak to your question we depend on security measures at
>>> the desktop and good user behavior to protect the long lived sessions
>>> (comparatively speaking) which users have to do anyway since we use
>>> Google. I am wrestling with the issue of sessions and whether or not its
>>> an IdP issue or not for my organization. Since Shib is replacing another
>>> home grown web authn solution that did not have a notion of SSO, I am of
>>> the belief currently that we have to support short sessions  and that it
>>> is an IdP issue due to that migration or risk slow adoption or outright
>>> rejection. When I have more time I will probably explore the option of a
>>> short session IdP run in parallel with my existing IdP.
>> --
>> Chad La Joie
>> www.itumi.biz
>> trusted identities, delivered
>> --
>> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>
>
> --
> John P. Mitchell <jpmitchell at alaska.edu>
> 907.450.8320
> http://www.alaska.edu/oit/iam
>
> "All mankind is divided into three classes: those that are immovable,
> those that are movable, and those that move." - Benjamin Franklin
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered