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

[Greg Wilkins <[e-mail]>]

John,

>From the point of view of a combined HTTP/websocket server, it would
be simplest if we can just use existing mechanisms for things like
BASIC, DIGEST, OAUTH, OpenID, acegi, NTML etc. etc.
So while there may be better security mechanism that could be applied
to websocket only client and servers, it would be unproductive to
prohibit the use of existing security mechanism if a way can be found
to use them.

For some of these, providing credentials ahead of time may be
sufficient, but others will be issuing challenges with nonces that
will need to be handled etc.  For the mechanisms that are already
supported in browser (BASIC, DIGEST), I would not think it would be
too difficult to support those if the browser had previously collected
credentials from the user (and it could just fail if it had not).

The hard ones are the mechanism that are not supported in the browser,
but in js libraries.  If they depend on headers, redirects and other
status codes, then such things need a way to be tunnelled through the
websocket API. I completely understand the reluctance to allow
arbitrary headers to be passed via the websocket API, yet I'm
concerned that will drive us to having to recreate new security
mechanisms that will in the end probably require some control over
headers anyway.  So I think the first step is to remove the
prohibition on using these mechanisms and then to build the consensus
on the use-cases that might justify support in the ws API.

cheers




On 30 August 2010 12:18, John Tamplin <[e-mail]> wrote:
> On Sun, Aug 29, 2010 at 8:44 PM, Greg Wilkins <[e-mail]> wrote:
>>
>> I do not think servers will be a problem, since if you use a HTTP
>> server that supports websockets, then it is very likely to just allow
>> arbitrary HTTP conversations to take place before the upgrade (as you
>> would have to do actual work to prevent that). Jetty certainly
>> supports this.
>>
>> The problem will be the clients.  There is nothing compelling the
>> clients to open websocket connections using their HTTP stacks, which
>> may be capable of handling redirections, 401's, set-cookies and other
>> HTTP stuff commonly used for authentication and authorization. Even if
>> the clients do use their HTTP stacks for the websocket handshake,
>> there are problems with some features (eg 401's) which need
>> interaction from a user, as their may not be appropriate UI mechanisms
>> associated with websocket.  So either you will need to develop your
>> own client that you know will support the features that you want, or
>> their has to be a commonly accepted set of HTTP features that commonly
>> deployed websocket capable browsers will accept.
>>
>> My feeling is that the browsers vendors are less keen on supporting
>> HTTP features on websocket handshakes, while the server vendors are
>> very keen.  I think some time and experience with real deployments is
>> needed for those two positions to converge.  Thus I think at this
>> stage having the prohibition on such features removed is the best we
>> can expect and that will allows  servers/browsers to experiment with
>> supporting HTTP features.
>
> I agree that we need to solve authentication with WebSockets, but it isn't
> clear emulating HTTP Auth is the best answer.  Since the connection is under
> program control and the program has presumably already authenticated itself
> with the server, perhaps just providing a way to pass credentials to the
> WebSocket constructor (which would then be passed in the handshake) would be
> sufficient.  Of course that could always be done by client and server
> agreement to send the credentials as the first message, though it may be
> common enough to support it directly rather than having every app reinvent
> it slightly differently.
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>