Modify forceAuthn Authentication Engine Behavior

[John Mitchell]

Chad,

On 12/15/2011 02:50 PM, Chad La Joie wrote:
> No, I understand what you're asking for, but it's *not* a software issue.
>

    I generally agree with that. Management does not though, and I live
between the software and the management.

> 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.

     I agree, so we are saying the same thing. I think somehow we just
do not agree on your first sentence though: "If applications care about
sessions, then forceAuthn is what they need." The logical conclusion to
your statement is that if an app cares about a session it cares about
the details of the session for some reason like shortening the session
or terminating the session at the IdP. Asserting forceAuthn at the
application does not affect either of those things it just asks the IdP
to prompt the user to authenticate again (it might even lengthen the
session as I notice the AuthnInstant is changed). This is not a function
of the session so much as it is a function of something like level of
assurance or security profiles. I would argue that another option is
needed like a supported logout method that the application can invoke
that logs out up to the IdP. You appear to be addressing the issue of
session length in v3 so my assertions about that are generally moot. In
fact if one can sync up the applications session length to the IdPs
session length dynamically, then maybe my assertion about needing logout
is moot as well, since the session will be expired anyway.

> 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.
>

    I look forward to that. Looks like maybe I will live with my hacked
together logout process that covers most of the bases for now and then
assess the feature you are referring to in v3.

> 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.

    Hmm. Users will always 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
>>
>
>


-- 
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