Re: [hybi] About authentication mechanism

Ian Fette (イアンフェッティ) <ifette@google.com> Wed, 22 June 2011 00:56 UTC

Return-Path: <ifette@google.com>
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 D2DF421F851F for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.545
X-Spam-Level:
X-Spam-Status: No, score=-105.545 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 kenWesY5+QUN for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:56:11 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id F352221F8523 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:10 -0700 (PDT)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p5M0uAa7019840 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308704170; bh=74TWAiYzbVNP494xdqf6r70zZaU=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=kQcF7qvakdCxrwOXfcdmrbpjPFZ7xpD/X8SPzax/YihPM50ZSd69oll/rD91U51JW eod9CTYdbOppHWmEoGyMA==
Received: from iyl8 (iyl8.prod.google.com [10.241.51.200]) by wpaz13.hot.corp.google.com with ESMTP id p5M0u8n8020314 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:09 -0700
Received: by iyl8 with SMTP id 8so350806iyl.0 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aysEvAUP4WqjnQ+79Oke7GALBRuT996GF0vkEPBJB2o=; b=px06DKSo0u1/rG8+KKAbJU4UnwnzXwqTo2cAjZ/Cxe9L1UHTZ+xumGOrKvYosgZaEm zp+qc+18xVQtYsAaQuFg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=WzyJFBLe24+tTcHCbWkRcYZSdPe7Z9nx8gmtqCAUAp/U77lUU+AwuPan3jTgSERna0 svP+Rf38TMDfcjFbsfZQ==
MIME-Version: 1.0
Received: by 10.42.159.68 with SMTP id k4mr84233icx.117.1308704168538; Tue, 21 Jun 2011 17:56:08 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Tue, 21 Jun 2011 17:56:08 -0700 (PDT)
In-Reply-To: <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@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>
Date: Tue, 21 Jun 2011 17:56:08 -0700
Message-ID: <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=90e6ba6137b214f0d904a6426f37
X-System-Of-Record: true
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
Reply-To: ifette@google.com
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:56:11 -0000

On Tue, Jun 21, 2011 at 5:20 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

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

How would you do it if you weren't using WebSockets but instead XHR? I doubt
you would use HTTP auth...


>
> 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'm not assuming they're on the same host. Certainly at Google that would
not be the case.


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


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