Re: [hybi] About authentication mechanism

Iñaki Baz Castillo <ibc@aliax.net> Wed, 22 June 2011 00:20 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D61D9E800F for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level:
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJV1+yQpjQRm for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:20:38 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF99E8004 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2954748qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr13397qcq.230.1308702037140; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
In-Reply-To: <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com>
Date: Wed, 22 Jun 2011 02:20:37 +0200
Message-ID: <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2011 00:20:42 -0000

2011/6/22 Ian Fette (イアンフェッティ) <ifette@google.com>om>:
> I would not want to support this from the browser side. We finally are
> starting to kill in browsers HTTP AUTH dialogs created by subresources
> (images etc). Frankly it's a very poor user experience. I think most people
> will use WS the way they use XHR + long polling, namely they will be on an
> established page, do their authentication however they do their
> authentication, set a cookie and move on. In some small corner of the
> universe, a small set of applications may continue to use HTTP AUTH, but I
> don't feel compelled to go out of the way to make its use any easier than if
> I had requested javascript from another origin which popped up an auth
> dialog. (Rather, I would probably block that as a browser).

So what about if the websocket server is not the same as the web
server from which the JS code has been got? Would the WS handshake
request include a Cookie header (that replied in the HTTP 200 OK from
the server? so, should the separate websocket server do some magic
with the Cookie value to verify ist validity?

Many web servers store the sessions data in memory so, which kind of
exotic mechanism should use the separate websocket server to validate
the given Cookie? use a shared database or shared memory (i.e.
memcached) for storing sessions?

Honestly I'm a bit afraid about your assumption in which clearly you
assume that the websocket server listens in the same host as the web
server. I strongly think that the protocol should define a well
specified and feasible authentication mechanism instead of assuming
that develovers will do some kind of magic in server side (a protocol
should not require that).

Regards.

PS: I agree that prompting the user with HTTP authentication dialog is
a pain, but I'm not suggesting that for websocket. In other thread I
explained how the JavaScript code retrieved by the browser (after user
login using whatever mechanism) could containg the WS URI connection
along with authentication information (i.e. user and pass for Digest
auth). Then the browser contacts the websocket server (don't assume
it's co-located with the web server), receives the 401 containing the
realm and nonce to use, and generates a new WS handshake request with
proper authentication credentials. This would prompt nothing to the
user.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>