Re: ACTION-11 SSO & Federated Identity

On 2006-12-06 21:09:44 +0900, Michael(tm) Smith wrote:

>> Case 0. User establishes TLS session, signs on with
>> username/password (usually with form post, sometimes http basic
>> auth) server takes down TLS for rest of session.

>> [Should we worry about this case? Although password is
>> protected from interception, there is no binding to rest of
>> interaction allowing session hijack, interception of app data,
>> etc. User sees lock during initial interaction and believes
>> session is "secure."

> Do you have any examples of sites that actually do this? (Or can
> you create one for testing purposes?) Or can you descibe what
> browsers currently do when they encounter this case?

This is a pretty typical pattern for the "big" content providers --
e.g., Yahoo and Google both do it.

Basically, authentication state is mapped into a cookie with a
limited lifetime, which can then be verified easily.  When the user
tries to do actions deemed "dangerous", then they are asked to
re-authenticate, and get a new cookie, or are moved into a constant
TLS mode.

One of the perceived benefits of this approach is that the servers
that provide the individual services can operate on a lower trust
level -- after all, they neither know the service's TLS certificate,
nor do they touch "real" client credentials.

Cheers,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 6 December 2006 14:59:18 UTC