Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 45035 invoked from network); 12 Jan 2010 22:06:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Jan 2010 22:06:59 -0000 Received: (qmail 72171 invoked by uid 500); 12 Jan 2010 22:06:58 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 72081 invoked by uid 500); 12 Jan 2010 22:06:58 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 72071 invoked by uid 99); 12 Jan 2010 22:06:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jan 2010 22:06:58 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of matteo.caprari@gmail.com designates 209.85.219.216 as permitted sender) Received: from [209.85.219.216] (HELO mail-ew0-f216.google.com) (209.85.219.216) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jan 2010 22:06:49 +0000 Received: by ewy8 with SMTP id 8so285867ewy.32 for ; Tue, 12 Jan 2010 14:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=MnkeLk2NF3j7TrXCc0Gaaxk6ZVtLD7aKBtim4dgkbMs=; b=n4Q1G/0vqQEss2J3tJb0VjvwtU3BSce/ZEl1xy8OZcoLUZMoWs1R3h9PvAYb4Vo+bA l39cCs5Sgd0sjR8x833e7KolmeHroRYp7zoWkpMdM1dvc+BAhFquGER9JwDHY+mjnLIu 2zfcab0DiGuB+B7eT8c9bS1ZoftQYtwxWDsRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=eC35LKDNdazRfPYzQsn86FyQ3wKnpxrwLxTPfSeJbniatdVtKbULcnKpIgzf4V3A3S k/6br3P/pskoFynXtwvKM05hCpsGwRCYJBe6JX6w9dHYAtq4ruvQF8DT4H/sPG6RrEQu Q15M9jAgSTvwZYCcYwg7AY2ASkejBmZXEdumI= MIME-Version: 1.0 Received: by 10.216.89.5 with SMTP id b5mr971964wef.143.1263333987130; Tue, 12 Jan 2010 14:06:27 -0800 (PST) In-Reply-To: References: <1bca98391001110634i313fa8e1k899d08adc3bf1543@mail.gmail.com> <20100112092803.GB4916@uk.tiscali.com> <1bca98391001120201o54760449lc38a0000856bcb4a@mail.gmail.com> From: Matteo Caprari Date: Tue, 12 Jan 2010 22:06:07 +0000 Message-ID: <1bca98391001121406m53564916h8fd06630b27c33c1@mail.gmail.com> Subject: Re: draft openid implementation To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 You're right. Simple and works, too. To recap: - a roundtrip to the endpoint verifies user claim of - the user with id org.couchdb.user: is loaded or created and loaded - a cookie is installed using couch_httpd_auth:cookie_auth_header from now on _session returns the right stuff. Some stuff is not quite right yet: - salt is not random - it only sopports openid 1.1 - it has only been tested against my blog and myopenid.com eopeind author suggested another library that may support openid 2, I'll try to add it after a code cleanup and some tests. To test, hit http://caprazzi.net:5984/_session?openid=auth-request&openid-identifier= You should be redirected to your your provider and then back to caprazzi.net. After that go to _utils and see how futon likes it. cheers On Tue, Jan 12, 2010 at 4:52 PM, Chris Anderson wrote: > On Tue, Jan 12, 2010 at 2:01 AM, Matteo Caprari > wrote: >> An openid signup should create a real user in the system, so apps need >> not to know about openid. As for roles I think by defult no roles >> should be added, but I may be wromg here. >> >> The implementation is so short of functionalities that everything is >> up for debate, but in short this is my plan: >> >> - user, couch and endpoint interact so that the couch verifies that >> the user owns the id >> - couch tries to find a user mapped the userid >> - if a user is found, a cookie compatible with couch_httpd_auth is installed >> >> - if a user is not found, this is a signup process: a new user >> document is stored and a cookie is given to the client. The user can >> then optionally be prompted to change his username. >> >> As a user may be mapped to multiple openids, I think the user document >> could contain a an array of verified openids for that user. >> >> { >> _id: 'org.couchdb.user:', >> username: , >> openid: [], >> roles: [] >> } >> >> - openid-to-user mappings could also be stored in separate documents, >> especially if we don't want to bloat the user document with all future >> authentication schemes. >> - I haven't figured out exactly how to generate a cookie that works >> with the standard auth. > > This sounds reasonable to me. The cookie-making code should be in > there, I think it is pretty simple. > >> >> -teo >> >> On Tue, Jan 12, 2010 at 9:28 AM, Brian Candler wrote: >>> On Mon, Jan 11, 2010 at 02:34:23PM +0000, Matteo Caprari wrote: >>>> - It uses its own cookie scheme to maintain authentication. Ideally it >>>> should install >>>> a cookie compatible with couch_httpd_auth, but that requires mapping >>>> an openid to a real user or >>>> creating a real user. >>> >>> How do openid users get assigned to roles, or is that not done? >>> >>> Does that mean that your application's validate_doc_update currently has to >>> have hard-coded the capabilities for individual openids? >>> >>> Thanks, >>> >>> Brian. >>> >> >> >> >> -- >> :Matteo Caprari >> matteo.caprari@gmail.com >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > -- :Matteo Caprari matteo.caprari@gmail.com