28 messages in org.oasis-open.lists.security-servicesRE: [security-services] Use Cases| From | Sent On | Attachments |
|---|---|---|
| Beach, Michael C | Oct 23, 2003 12:49 pm |  .bin, .doc |
| John Kemp | Nov 24, 2003 1:58 pm | |
| Beach, Michael C | Nov 25, 2003 11:24 am | |
| Greg Whitehead | Nov 25, 2003 11:50 am | |
| Beach, Michael C | Nov 25, 2003 12:24 pm | |
| Greg Whitehead | Nov 25, 2003 12:32 pm | |
| John Kemp | Nov 26, 2003 6:20 am | |
| Scott Cantor | Nov 26, 2003 8:22 am | |
| John Kemp | Nov 27, 2003 7:49 am | |
| Scott Cantor | Nov 28, 2003 9:30 pm | |
| Conor P. Cahill | Nov 29, 2003 2:14 am | |
| Conor P. Cahill | Nov 29, 2003 2:25 am | |
| Conor P. Cahill | Nov 29, 2003 2:27 am | |
| John Kemp | Nov 29, 2003 5:54 am | |
| Conor P. Cahill | Nov 29, 2003 11:35 am | |
| Beach, Michael C | Nov 29, 2003 11:37 am | |
| John Kemp | Nov 29, 2003 11:52 am | |
| Beach, Michael C | Nov 29, 2003 11:59 am | |
| Beach, Michael C | Nov 29, 2003 12:03 pm | |
| Conor P. Cahill | Nov 29, 2003 1:46 pm | |
| Conor P. Cahill | Nov 29, 2003 2:59 pm | |
| Anthony Nadalin | Nov 30, 2003 5:23 pm | |
| Conor P. Cahill | Nov 30, 2003 7:18 pm | |
| Conor P. Cahill | Dec 1, 2003 4:16 am | |
| Anthony Nadalin | Dec 1, 2003 9:31 pm | |
| Conor P. Cahill | Dec 2, 2003 4:38 am | |
| Anthony Nadalin | Dec 3, 2003 4:36 am | |
| Conor P. Cahill | Dec 3, 2003 4:54 am |
| Subject: | RE: [security-services] Use Cases | |
|---|---|---|
| From: | Conor P. Cahill (conc...@aol.com) | |
| Date: | Nov 29, 2003 2:14:25 am | |
| List: | org.oasis-open.lists.security-services | |
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