OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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