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 2B4689483 for ; Sun, 23 Oct 2011 11:35:52 +0000 (UTC) Received: (qmail 36083 invoked by uid 500); 23 Oct 2011 11:35:50 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 36043 invoked by uid 500); 23 Oct 2011 11:35:50 -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 36035 invoked by uid 99); 23 Oct 2011 11:35:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Oct 2011 11:35:50 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ido.ran@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-iy0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Oct 2011 11:35:45 +0000 Received: by iakc1 with SMTP id c1so9382108iak.11 for ; Sun, 23 Oct 2011 04:35:25 -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=QX7UX/6W8Gh72u451ETpV1OCtYRiPp72V5nEQ8DnSbM=; b=pamfB5Ym90+fIn+Rmv51pBk/X8pdbw54Hjn4gGZxfOfswTyfZoGjupG8ENfolq829z fc2OtD1ncHO5imZDEadZVCaQMNYuE2Tb+Qd4QQ5GAftWfrLLviis5cqhH1gVx5C4mzZ/ /c9nTloWoYspGRDWp94aGEFvcpy9OCi/wrsfI= Received: by 10.42.135.66 with SMTP id o2mr3401484ict.0.1319369725087; Sun, 23 Oct 2011 04:35:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.176.132 with HTTP; Sun, 23 Oct 2011 04:34:55 -0700 (PDT) In-Reply-To: References: <36E79CEC5BFB8E4D9763C4DEB9B1163C38970AA243@UK-EXCHMBX1.green.sophos> From: Ido Ran Date: Sun, 23 Oct 2011 13:34:55 +0200 Message-ID: Subject: Re: Authentication Question To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=90e6ba6e89d6ca8f7404aff5b34a --90e6ba6e89d6ca8f7404aff5b34a Content-Type: text/plain; charset=UTF-8 Hi Marcus, Sounds like you really solve the login via 3rd party cleanly. Can you please refere me to some code or document explain it in more details? Also, is it possible to extend such solution to use CouchDB replication? Thank you, Ido On Thu, Oct 20, 2011 at 4:55 AM, Wordit wrote: > 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 > --90e6ba6e89d6ca8f7404aff5b34a--