| 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] Re: ForceAuthn (was Use Cases) | |
|---|---|---|
| From: | Conor P. Cahill (conc...@aol.com) | |
| Date: | Nov 29, 2003 2:59:36 pm | |
| List: | org.oasis-open.lists.security-services | |
Just a clarifying note... We have been talking back and forth about caching of credentials and prompting of the user that I thought I would walk through the authentication process discussing what an IdP might do and when..
User has an estabilshed session at the IdP (started via an authentication event at the IdP) and browses to an SP. The SP submits an AuthnRequest to the IdP to initiate SSO on behalf of the user. At this point the IdP may:
a) use the established session information to enable SSO with the SP. b) authenticate the user using the appropriate means required for the authentication context requested by the SP. c) return failure for any of a number of reasons.
The IdP chooses which of these it will perform based upon a number of factors including the parameters of the request from the SP, the general policies at the IdP and, potentially, the user preferences about SSO at the IdP. For example, the IdP would likely perform (b) if the ForceAuthn flag is set on the request or if the Authn that initiated the session is old enough that IdP policies require a reauthentication.
Note that (a) is not permitted, IMHO, if ForceAuthn is set since (a) does NOT involve an invocation of the authentication process, but rather the IdP re-reading some of its session information and that, IMHO, is not a re-authentication.. However, (b) may involve authantication interactions with the user's client that are invisible to the user.
Conor






.bin, .doc