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

[Hector Santos <[e-mail]>]

John Tamplin wrote:
> On Sun, Aug 29, 2010 at 8:44 PM, Greg Wilkins <[e-mail]> wrote:

> 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.

+1, IMO, this would be a session management implementation issue.

We had this design requirement since 1996 with our multi-device 
connections and dealing with common user session management between 
the different clients.  The server will always need to check and 
secure for independent websocket entry points.

Whether a server application needs call for signaling an 
authentication requirement via websocket is another subject to discuss.

In our design, we have two clients that can be started via a browser - 
one Native GUI, the other Java-Based. They both start a TCP session 
for interactive I/O communications over a PPP framing API layer/wire. 
So two sessions are started - one browser, one non-browser.

Regardless of how authentication takes place via browser, HTTP AUTH or 
cookies, when the non-browser is launched, a session id is passed 
which will clone the session.

If the login takes place via the native GUI client, the user has an 
option to open a homepage browser session by passing a session id as 
part of the url.

No matter what method and direction is used, the backend server needs 
to control/secure all that any way.

Overall, the issues we experience is controlling direct url request 
that might bypass the initial authentication and/or cookie settings, 
including javascripting requirements.

I don't currently see how websockets will change this or the need 
correct session management on the back one.

The following illustration can illustrate the point:

    http://www.winserver.com/public/vimg.wct?src=wcrpcnet7.png

The light yellow WCRPC is our missing piece and WEBSOCKET is what we 
excited us to possibly use.  But User can connect with any of the 
yellow WCN clients.

Session management controls is important and I will also note to 
product managers it might change any user/node licensing you have.  It 
was one of the first things we had to do back in 1996 since users were 
no long connecting just one way.


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