28 messages in org.oasis-open.lists.security-servicesRe: [security-services] Re: ForceAuth...| 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: | John Kemp (onez...@bcn.net) | |
| Date: | Nov 29, 2003 11:52:43 am | |
| List: | org.oasis-open.lists.security-services | |
Mike,
As others have previously pointed out, an SP could request an appropriate minimum authentication context when making the authentication request. That context could specify that a direct user interaction is made by the IdP. Such a usage would preclude the use of cached credentials by the IdP, and force them to either interact with the user or return a failure code to the SP.
- JohnK
On Saturday, Nov 29, 2003, at 14:42 US/Eastern, Beach, Michael C wrote:
JohnK said:
I guess the ultimate question though is whether we think that ForceAuthn semantics that allow a situation where the *user* is not challenged are sufficient for the SP, and if not, is this a problem?
------------------------------------------------- Mike Beach says:
From a business perspective that would be a problem. The driver behind our interest in this is to address the situation where a user leaves a workstation unattended after authentication. The SP requires the session be reauthenticated after 20 minutes idle time. If the reauthentication occurs without user challenge, the intent is missed.
However, from a technology perspective we have similar problems today with cached credentials, and I am not sure there is any way for us to prevent that. The mechanisms for caching credentials are intended for ease of use at the potential expense of security, and are implemented in components of the environment clearly outside the scope of our standards efforts.
Mike
-----Original Message----- From: John Kemp [mailto:onez...@bcn.net] Sent: Saturday, November 29, 2003 6:00 AM To: Conor P. Cahill Cc: Scott Cantor; 'Greg Whitehead'; Beach, Michael C; secu...@lists.oasis-open.org Subject: Re: [security-services] Re: ForceAuthn (was Use Cases)
On Saturday, Nov 29, 2003, at 05:31 US/Eastern, Conor P. Cahill wrote:
Scott Cantor wrote on 11/29/2003, 12:36 AM:
Well, your point is certainly well taken, but I guess I wasn't necessarily equating ForceAuthn with "InteractWithUser". To me, all this says is for the IdP to at least check the authentication status of the user, following *their* policy. This may include a user interaction, but as you point out below, it may not. So, perhaps the term 'ForceAuthn' is somewhat misleading?
"checking authn status" sounds a little light for something that I thought was meant to imply a bypassing of SSO.
I agree. I like to think of ForceAuthn as the SP asking the IdP to do whateve it takes so that the IdP can update the AuthenticationInstant in the assertion at this time.
And that is my understanding too. I was merely pointing out that Scott is actually right - it may not involve a user interaction, and may simply involve checking a cached cert. without any active, direct user re-authentication at all. So, the term "ForceAuthn" could be misleading.
For a UserName/Password authentication, this means it is a challenge to the user. For some other authentication methods (such as an X509 certificate, the IdP can challenge the client, but the IdP doesn't have control what the client does with the user, so there may be a soe cases where there is no challenge to the user).
Right - we're all in violent agreement.
I guess the ultimate question though is whether we think that ForceAuthn semantics that allow a situation where the *user* is not challenged are sufficient for the SP, and if not, is this a problem?
- JohnK
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/ members/leave_workgroup.php.