Modify forceAuthn Authentication Engine Behavior

[John Mitchell]

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