Re: [hybi] About authentication mechanism

Ian Fette (イアンフェッティ) <ifette@google.com> Wed, 22 June 2011 10:53 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 E201A11E80F2 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.367
X-Spam-Level:
X-Spam-Status: No, score=-105.367 tagged_above=-999 required=5 tests=[AWL=0.309, 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 qz62pdfPgLBN for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:53:01 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8AF11E80EC for <hybi@ietf.org>; Wed, 22 Jun 2011 03:53:00 -0700 (PDT)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p5MALjKP032019 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:21:45 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308738105; bh=tD78slwr6sjqclOrMuXaWvy5lLI=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=XTwMNdJmx3pzocIrdpAjPcJFDtIcHGqJnEAjpoONqvG9O7uRa+39bhXhXXTw3clkm fZb2h3WcDsEdNBM4CLj8w==
Received: from iyb26 (iyb26.prod.google.com [10.241.49.90]) by wpaz1.hot.corp.google.com with ESMTP id p5MALheO032429 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 03:21:44 -0700
Received: by iyb26 with SMTP id 26so616496iyb.9 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:21:43 -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=OnvS48sPG16kJR3Ppn98Wom6qmg0dPjdlkVb1dgFJl4=; b=sn+iNiJq42edE6A1W1AxKwku2OsLbblo5VhMNGRg6t5lbnyLCt6yPuzOcG/pzXwOI4 FqvirxfwKqcJBG11rgQg==
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=JXwNU1Mo6mxafS9hI8JfcdY4Lkn3abvNcE0HWvFq0vIeg4C0TIsHF24UOOF1CF0IfL rQFfRWdlLA2D9coEX7XQ==
MIME-Version: 1.0
Received: by 10.231.60.73 with SMTP id o9mr505938ibh.33.1308738103522; Wed, 22 Jun 2011 03:21:43 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Wed, 22 Jun 2011 03:21:43 -0700 (PDT)
In-Reply-To: <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@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> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com>
Date: Wed, 22 Jun 2011 03:21:43 -0700
Message-ID: <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@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=0015176f0d28c3b72604a64a5586
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 10:53:02 -0000

On Wed, Jun 22, 2011 at 3:06 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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.
>
>
>
XHR can be sent to a different origin. http://www.w3.org/TR/cors/


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

A desktop widget / android app / ... surely already faces this problem with
whatever communication mechanism they use, and I would be frankly amazed if
they expected to solve it with http auth...


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