Re: [hybi] About authentication mechanism

Iñaki Baz Castillo <ibc@aliax.net> Wed, 22 June 2011 10:07 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 2EB8011E8098 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:07:01 -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 miXZf72jwkzf for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:07:00 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 22D3E11E80CF for <hybi@ietf.org>; Wed, 22 Jun 2011 03:07:00 -0700 (PDT)
Received: by qyk29 with SMTP id 29so458600qyk.10 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:06:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr306752qcq.230.1308737219289; Wed, 22 Jun 2011 03:06:59 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Wed, 22 Jun 2011 03:06:59 -0700 (PDT)
In-Reply-To: <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@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> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com>
Date: Wed, 22 Jun 2011 12:06:59 +0200
Message-ID: <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@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 10:07:01 -0000

2011/6/22 Ian Fette (イアンフェッティ) <ifette@google.com>om>:
>> 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?
>
> How would you do it if you weren't using WebSockets but instead XHR? I doubt
> you would use HTTP auth...

Usually XHR is sent to the same web server (so using Cookie is very
suitable), am I wrong?
Note however I'm not an expert in XHR so maybe I miss something.



> I agree that a better solution would be to do whatever authentication you
> need when the user goes to the website, and then once the user is
> authenticated open the WS connection and pass some sort of credential. That
> could be via cookies if it's on the same origin, or it could be passed over
> the established WS connection. I don't know that it should be defined in the
> WS API though, as different sites might want to use vastly different
> authentication mechanisms (client-side certs, passwords, oauth, ...). It's
> much more flexible to leave it to the application.

Ok, but take into account that not all the WS connections would be
preceded by an access to a web page. Let's imagine a desktop wigdet
(or an Android app!) that directly open a WS connection (without
opening first a web page, so the client cannot authenticate via an
HTML form in "any custom way"). What to do then? How to prompt the
user for credentials? which authentication mechanism to use? So there
would be needed:

- An API for promting the user for credentials.
- A specified authentication mechanism for "pure websocket" connection
(without depending on a previous HTTP/HTML access).

Have the WG considered this case?


IMHO authentication should occur at protocol level, rather than at
application level. This is true in all the protocols of Internet but
HTTP, which is a jungle. But HTTP usually means displaying a web page
with some HTML form in which the user can interact by setting his
credentials, press "submit" and that's all. Such kind of
authentication level is not possible in WebSocket as a WebSocket
renders nothing to the user, a WebSocket server does reply a web page.

I still see the need to mandate the support of HTTP Digest
authentication in WebSocket (which involves an API and a section in
current specification.

Regards.




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