From user-return-18375-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Oct 20 02:56:57 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CDF5278A8 for ; Thu, 20 Oct 2011 02:56:57 +0000 (UTC) Received: (qmail 81240 invoked by uid 500); 20 Oct 2011 02:56:56 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 81155 invoked by uid 500); 20 Oct 2011 02:56:55 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 81147 invoked by uid 99); 20 Oct 2011 02:56:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2011 02:56:53 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of wordituk@gmail.com designates 209.85.216.180 as permitted sender) Received: from [209.85.216.180] (HELO mail-qy0-f180.google.com) (209.85.216.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2011 02:56:47 +0000 Received: by qyk10 with SMTP id 10so2729997qyk.11 for ; Wed, 19 Oct 2011 19:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=rHc/jvtHIpD8vAsCfOfNfqWOcpl1KYeZoq2Qc8gbY+8=; b=brP8HOobUSV1Vnf/RPY5r/OmKdvtmT8lKfSzq1bddEEjt5CSRLiPRtEPMxdK5t9FLh ViOkyK4lu5RAuYtOFiUSrSfFwiomIQKaEZDHBzb6H5bO83syEmYo5NlEFOq6qzJV/9Uc jSDFOgCss9LPUF1EkAT4HC5FsO7X08cqc1nyo= Received: by 10.229.12.209 with SMTP id y17mr1920705qcy.220.1319079386298; Wed, 19 Oct 2011 19:56:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.49.1 with HTTP; Wed, 19 Oct 2011 19:55:46 -0700 (PDT) In-Reply-To: <36E79CEC5BFB8E4D9763C4DEB9B1163C38970AA243@UK-EXCHMBX1.green.sophos> References: <36E79CEC5BFB8E4D9763C4DEB9B1163C38970AA243@UK-EXCHMBX1.green.sophos> From: Wordit Date: Thu, 20 Oct 2011 04:55:46 +0200 Message-ID: Subject: Re: Authentication Question To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Oct 19, 2011 at 11:59 AM, Paul Hirst wrote: > > If I can avoid it I'd rather not have users really exist in the _users database but if this is unavoidable maybe I could create them on the fly? Paul, I added users with existing logins to a couch db as needed. The existing system in my case was to use OpenID (and Facebook) logins, but the principal is the same. Authentication goes via another system, which talks to the third party login systems and then to the couch. It adds users to the couch as needed. Passwords are auto-generated and saved in an admin-only couch db. The neat thing being that even if anybody compromises the couch, the passwords are useless outside of this application. The actual login info the user enters is elsewhere, and the couch has no access to those systems (in this case being OpenIDs they are kept by Google, Yahoo, myOpenID etc). Once authenticated, the user is automatically logged in to the couch by getting the login details of the user's couch account, which it created earlier, and which is kept in a couch db. The _users db is also used, but users cannot login directly because they do not know the password which is stored in an admin-only db. The external authentication system sends info to the browser so the user can be logged in to the couch, with a cookie token. However, it never trusts the browser. All the browser sends over is the username of the user logged into the couch. Authentication is rechecked each time, which is easy and occurs without further user intervention. Users only do one login per session with their existing account. You can set a short-term session cookie or let the authentication system do its thing each time. Sounds a bit complicated and it was due the same-domain-policy issues (the elegant solution being PostMessage). It is rather good though because it gives you full control over the data and authentication. HTH, Marcus