[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Re: ForceAuthn (was Use Cases)
That would seem to move us toward the functionality we deem necessary. Mike -----Original Message----- From: John Kemp [mailto:onezero@bcn.net] Sent: Saturday, November 29, 2003 11:58 AM To: Beach, Michael C Cc: Conor P. Cahill; Scott Cantor; Greg Whitehead; security-services@lists.oasis-open.org Subject: Re: [security-services] Re: ForceAuthn (was Use Cases) 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:onezero@bcn.net] > Sent: Saturday, November 29, 2003 6:00 AM > To: Conor P. Cahill > Cc: Scott Cantor; 'Greg Whitehead'; Beach, Michael C; > security-services@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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]