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: [no subject]


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=20
> in
> the assertion at this time.

And that is my understanding too. I was merely pointing out that Scott=20
is actually right - it may not involve a user interaction, and may=20
simply involve checking a cached cert. without any active, direct user=20
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=20
ForceAuthn semantics that allow a situation where the *user* is not=20
challenged are sufficient for the SP, and if not, is this a problem?

- JohnK=20
 =20


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/le=
ave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]