Modify forceAuthn Authentication Engine Behavior

[John Mitchell]

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.


> On Thu, Dec 15, 2011 at 16:09, John Mitchell <jpmitchell at alaska.edu> wrote:
>> Chad,
>>
>> On 12/15/2011 12:05 PM, Chad La Joie wrote:
>>> Thats what forceAuthn does.  So if the application always sends
>>> forceAuthn, then there will be no SSO.
>>>
>>    It does but it expects the same principal to login each time
>> forceAuthn is asserted when the IdP session is still valid right? That
>> was what I read from looking at the validateForcedReauthentication
>> method. In my applications case a different students will be logging
>> into the application from the same web browser for very short
>> application sessions. So setting the SPs session length very low and
>> asserting forceAuthn does not appear to work as desired.
>>
>>> On Wed, Dec 14, 2011 at 20:18, John Mitchell <jpmitchell at alaska.edu> wrote:
>>> For background: I am integrating an application
>>>> that wishes to have absolutely no SSO due to running in a highly shared
>>>> environment (kiosk that is used by students during registration). I am
>>>> almost of the mind to setup another IdP to solve this problem, but I do
>>>> not have the time and resources to do that right now.
>>
>> --
>> 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