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