Re: [hybi] WebSocket handshake (HTTP and SSO)

[Hector Santos <[e-mail]>]

Scott Ferguson wrote:
>> John Tamplin wrote:
>> How many websites actually use HTTP Auth to protect the data?  
> 
> Non-browser clients do. With Hessian (binary RPC over HTTP), HTTP auth 
> is very typical.
> 
> I'd prefer to build in WebSocket support to allow for a piggy-backed 
> DIGEST-style authentication, allowing the server response to send its 
> challenge and replace the clients first random bytes with an 
> authentication/hello frame, which would be the DIGEST credentials.

I can support the idea based on how Tamplin is viewing non-HTTP 
authentication method as the "new pseudo standard" - cookie-based 
authentication methods and how WebSocket is persistent with passing 
browser cookies.

So one may suggest to be also persistent with passing standard 
HTTP.Authorization headers as well.

Another related item is the draft to add cookie based Authentication 
schemes.

http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html

So perhaps websocket server should begin to pass

      WWW-Authenticate: scheme

headers with the anticipation standard WWW-Authenticate: cookie 
schemes will be available and supported by WebSocket clients.  I 
believe some already using the draft guideline.

Whether the server honors or support the Authorization here generated 
by the  websocket implementation is another matter.  But it might good 
to have it available and see how its employed.

It would definitely change how we currently authenticate secondary 
session channels. But I think its worth an exploration.

> Non-browser clients exist and are important. You can't assume all 
> interactions are from a browser.

+1.

> We do need to make one change in the handshake, because the first client 
> data (the random bytes) is the logical place to put authentication 
> credentials.

When not just use the a HTTP.Authorization header?

> If we just punt and make applications write their own authentication 
> instead of piggybacking on the handshake, it would cost an extra round 
> trip.

But you also can't prevent this - when an non-authenticate request 
comes in.

As I pointed out in a previous point, this was among the #1 issues we 
had in our framework.  It was tricky to get the right flows and it 
included redirection.

The question becomes can a websocket server trigger the websocket 
client to perform an authentication process and how is that done?

Is a 401 with WWW-Authenticate: headers sufficient?  Is a 403 
sufficient to short-circuit the request?  Do we need to redirect the 
websocket client?

etc.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com