Re: Introducing a Session header...

On 21/07/2012 2:19 a.m., Jonathan Ballard wrote:
> The SSO is something we negotiate between two or more origin servers, 
> and the UAs need not be part of that negotiation. It's may be the 
> simpler design step to use the UAs for such negotiation between 
> servers (with such "session header") after we establish the 
> connection, yet that does not help secure authentication.
>

Indeed. The securest setup for SSO is to have the cleint present unique 
session-ID to each server *also* to provide the same credentials.
Both servers knowing which DC to validate those credentials against they 
can register their internal state-reference to the account.
The client never sees any of the server IDs or federation activity. When 
done right eavesdroppers with access to both connections cannot link the 
two credential sets easily.

> The hint for redirection is correct, the origin server(s) may create 
> new resource, upon UA connection,  and encode any session/state in 
> that resource without affect to the headers.

Separate UA generated session-ID is *essential* here since the redirect 
may have been added/triggered by an attacker. Handing them a 
pre-authenticated session ID is not acceptible. The only hope of 
detecting and protecting against such attackes is to require the 
attacker to repeat the authentication process where they should get 
caught (if it was auth worth its cost).

Amos

Received on Saturday, 21 July 2012 00:28:20 UTC