Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of wout.mertens@gmail.com
 designates 209.85.215.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=l4xkrDbs/C6dMSOCnQa6pn8GtedmINUFKPRBy1nRkPqFtY7fazrfNO1Cu1ccZ0yRcP
         b0hvTqV4/HEZeG+lxDDCY1mMXuOeMu4oAtvKA/yPVf786LNjddXer2BHrcy496qrHnxN
         SQYLV9rppb6jkuYCHzSTNGqGKvOLSyPDG2tnc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Best performing login implementation?
From: Wout Mertens <wout.mertens@gmail.com>
In-Reply-To: <AANLkTinT3nqZgVJVXKh4wXUPJmTAOTjeadx9xZ9f1_dX@mail.gmail.com>
Date: Mon, 6 Sep 2010 20:03:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3319823F-25BE-4B59-84A7-CCB765C9CD36@gmail.com>
References: <AANLkTikh=56TEWh=OkPA8o-NiRsumcVrdRFeF4_nZ9cv@mail.gmail.com>
 <33F12002-C2C7-4F38-9010-F4B168D688A3@gmail.com>
 <AANLkTimA7cawgxvDK+oV+X=srPAcP=pfKOQoyEYjLqaU@mail.gmail.com>
 <DF7FAEBF-2E6A-43AE-ABCA-7F030CE346C9@apache.org>
 <6161665A-8BBB-4441-9FE9-37918CE35446@gmail.com>
 <3DAC56D6-6DB8-4A3E-8A36-453E42AE3AF6@apache.org>
 <AANLkTimPZP2ZtuN+YVKQ3kbaP2f0_kfMDNHxOT1jvs6O@mail.gmail.com>
 <DBF7D941-6624-4FA6-9425-99C711BD819E@gmail.com>
 <AANLkTinT3nqZgVJVXKh4wXUPJmTAOTjeadx9xZ9f1_dX@mail.gmail.com>
To: user@couchdb.apache.org

Flexible, granular per-document permissions are slow :-) So you have to =
implement a middle layer yourself that does the authorization as =
befitting you and talks to CouchDB.

Wout.

On Sep 6, 2010, at 19:34 , Tiago Freire wrote:

> It's a mix, and additionally there are specific documents from each =
client
> which may be shared with one or more of the other users, or even made
> public, but that's casa-by-case. Flexible, granular per-document =
permissions
> are needed.
>=20
> On Mon, Sep 6, 2010 at 2:21 PM, Wout Mertens <wout.mertens@gmail.com> =
wrote:
>=20
>> If you store confidential information, they can be in 2 categories
>> 1. data the user has to be able to read
>> 2. data only you have to be able to read
>>=20
>> So if it is category 1, simply add a database for that data =
(remember, many
>> databases per couchdb server) and add only the user to the readers.
>>=20
>> If it is category 2, put all that confidential data in a database and =
add
>> only your server user to the readers.
>>=20
>> If it's a mix, implement 2 and expose some of the info through your =
server
>> scripts for the user to use. I wonder if you can use the CouchDB
>> authentication in that case though :-/
>>=20
>> Wout.
>>=20
>> On Sep 6, 2010, at 19:15 , Tiago Freire wrote:
>>=20
>>> 'Users can read the entire database' is a big no-no for our design. =
We
>> store
>>> confidential information from our clients an they cannot see each =
others'
>>> stuff.
>>> Now, the 'everyone-can-read' model is all the CouchDB authentication
>> system
>>> offers, or it is just a default, and I can restrict reading using =
the
>>> default authentication scheme?
>>>=20
>>>=20
>>> On Mon, Sep 6, 2010 at 1:38 PM, J Chris Anderson <jchris@apache.org>
>> wrote:
>>>=20
>>>>=20
>>>> On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
>>>>=20
>>>>> On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
>>>>>=20
>>>>>> Also it is worth noting that CouchDB has a builtin authentication
>> system
>>>> that gets this right, and you might just be able to piggyback on =
it,
>>>> depending on your application:
>>>>>>=20
>>>>>>=20
>>>>=20
>> =
http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-secur=
ityn-stuff
>>>>>=20
>>>>> So the security model is:
>>>>> - Admins can do everything on all local databases
>>>>> - Readers can read the entire database
>>>>> - Writes can have any model you like with validation functions
>>>>>=20
>>>>> So if you want to segment your database readers you have to =
segment
>> your
>>>> databases.
>>>>>=20
>>>>=20
>>>> Yes.
>>>>=20
>>>>> Furthermore, if you would like to use LDAP authentication, you'd =
have
>> to
>>>> use an LDAP-to-OAuth server.
>>>>>=20
>>>>=20
>>>> It should be a very simple patch to add new Erlang authentication
>> handlers
>>>> for things like LDAP, Kerberos, etc. That might be simpler than =
adding a
>>>> bunch of glue to speak OAuth.
>>>>=20
>>>>> Correct?
>>>>>=20
>>>>> Wout.
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> --
>>> -----
>>> Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
>>=20
>>=20
>=20
>=20
> --=20
> -----
> Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe