OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Use Cases


Mike, Greg et al,

See comments inline:

On Tuesday, Nov 25, 2003, at 14:55 US/Eastern, Greg Whitehead wrote:

>
> On Tuesday, November 25, 2003, at 01:29 PM, Beach, Michael C wrote:
>
>> John, yes that does make sense.
>>
>> As a result of today's telecon about reducing the scope of this item, 
>> I was considering the implications of session authorities not 
>> addressing idle timeout.
>>
>> Givens:
>> - We have service providers that have some sort of mandatory timeout 
>> restriction (preferably idle, but we don't have that today)
>> - Service providers typically have need to create local sessions 
>> (either legacy or to streamline interaction)
>>
>> Consideration:
>> Multiple sessions without global idle timeout monitoring could be a 
>> reasonable compromise.
>>
>> I still see need for some kind of independent management of sessions 
>> for collections of SPs, where each collection is made up of 1 or more 
>> SPs with similar security policy.  Then if we could at least provide 
>> a mechanism for a service provider to signal a session termination or 
>> re-authentication required?  The issue I have today is SPs that want 
>> to do some kind of timeout (or session logout) and force a 
>> re-authentication for their session only.  Because we have an SSO 
>> implementation (single global session), a re-authentication event is 
>> handled automatically by the authentication authority without user 
>> interaction.  The SP considers that a security flaw, potentially to 
>> the point that the SP will not participate in our enterprise SSO 
>> initiative.  If the SP had a means to control "their" session, I 
>> could likely sell the compromise.
>
> The Liberty AuthnRequest has a flag called ForceAuthn that can be used 
> by an SP to force the user to be re-authenticated even if the IdP has 
> an active session with him/her. In the context of this session 
> discussion, I can imagine a slightly different mechanism being useful, 
> where the SP could signal the 'freshness' of authentication that it 
> finds acceptable. In other words, if it has been >N seconds since the 
> user was last authenticated in the current session, re-authenticate 
> him. This would perform better in a multi-SP scenario where the user 
> remains idle at two different SPs for some period of time greater than 
> the idle timeout and then revisits them both in a short time interval.

I think that Greg's proposal is an excellent one. I would also point 
out that individual SPs have a lot of control over what they do locally 
- they can invalidate a user's local session at any time they wish to, 
without requiring any global protocol to manage it. With the ability to 
force re-authentication at a certain time after the previous 
authentication, through the protocol, they get even more control over 
this process. I've cc'd Scott who's working on the SSO requirements to 
make sure he sees this.

>> The clearly stated business scenario does call for global idle time 
>> tracking, but something is better than nothing.
>
> Not having global idle time tracking impacts the user experience, I 
> guess, but at least it doesn't compromise security. Having each SP 
> track idle time independently may lead to sessions being expired 
> sooner than they otherwise would (but not later).

Yes, exactly... we're not precluding effective idle timeouts by not 
including such facilities in the SAML protocol. And we're also not 
precluding the possibility of individual implementations from 
developing a global idle timeout facility.

- JohnK



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]