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


I was envisioning the SPs would communicate with the IdP, not necessarily with each other.  

Your comment about user financial sites is fundamentally what is driving my interest in this.  I am looking for some way to provide increased security at such sites while allowing them to participate somehow in the SSO environment.  The challenge seems to be to find some level of compromise that provides sensible, secure behavior from a user perspective without undue technical complexity and overhead.

Mike

-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: Saturday, November 29, 2003 2:21 AM
To: Beach, Michael C
Cc: John Kemp; security-services@lists.oasis-open.org
Subject: RE: [security-services] Use Cases




Beach, Michael C wrote on 11/25/2003, 2:29 PM:
 >
 > 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.

I am concerned about creating any form of multiple SP, over the wire, 
session management.  The issue here is how does the SP get a handle that 
it can use to talk to other SPs about the same user.

I think that the IDP has to have some form of SessionIndex on it's 
assertions in order to properly handle Single-Log-Out in a world where 
the user may have multiple simultaneous authentication sessions (such as 
browsers on two different computers -- where logging out of SSO on one 
computer shouldn't impact your session on the other computer).

I think that the SP is on its own with respect to local session 
management.  Groups of SPs can do this with some for of common domain 
cookie.

 > Then if we could at least provide a
 > mechanism for a service provider to signal a session termination or
 > re-authentication required?

SPs can signal the termination of an IdP session for the user via the 
SLO protocol.  The SP can also use ForceAuthn to signal that a 
re-authentication is needed.

But the SP can't signal (to anybody other than the user) that it's local 
session has been terminated.  We could add SPLO (SP Log Out) capability 
(for the SP to be alble to tell the IdP that the SPs session initiated 
by the SSO has been terminated) to the SLO protocols if we feel that is 
necessary.  However, the only effect of such a call would be that the 
IdP would not send an SLO notificcation to thhat SP should real SLO be 
initiated at the IdP.  The SPLO would not cause the IdP to send SPLO 
notifications to other SPs.

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

I agree, although I would say that the IdP wants the ability to do this 
as well.  So with the current SSO protocols in ID-FF, the SP can, when 
it determinees that the authenticationInstant is too old, submit an 
AuthNRequest to the IdP with ForceAuthn set to true.   The SP can do 
this immediaitely after receiving an assertion (e.g. Sp gets 
AuthnResponse, examines the assertion and decides it's too old and 
therefore submits another authnrequest with ForceAuthn).

 > Because we have an SSO
 > implementation (single global session), a re-authentication event is
 > handled automatically by the authentication authority without user
 > interaction.

This is only the case if the policies implemented at the IdP (hopefully 
with some level of user control) allow it.  The IdP couldd have policies 
that it must re-authenticate the user every x hours or the user may have 
set a preference on the IdP to always be challenged when a particular SP 
submits an AuthnRequest (I could see some users doing this on one of 
their financial sites).


 >  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 SP can always control their session and, to some extent, the session 
at the IdP.  It just can't control sessions at other SPs.

 > The clearly stated business scenario does call for global idle time
 > tracking, but something is better than nothing.

Right now the only things that SPs have the ability to control is "time 
since last authentication" and the local session characteristics once a 
local session is initiated from the SSO operation (e.g. they can still 
do an idle time-out on their own site).

Conor



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