couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: auth per db - thoughts and question
Date Sun, 01 Nov 2009 18:59:19 GMT
On Sun, Nov 1, 2009 at 3:33 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> Hi,
>
> I'm working on a authentification per db for couchdb. I failed to find
> a right system actually and trashed my code this morning. Suggested by
> Jan, I post here my thoughts about it. Main goals are :
>
> - Set permission read or write for users on a db

I think the goal of getting this level of permissions is enough for
one patch. Throwing replication into the mix adds a whole level of
complexity.

Imagine the user credentials are stored in the "users" db on node A,
and user Bob own db "foo" on node A, while user Alice has read-only
access to "foo" on node A.

If Alice replicates "foo" to her laptop, Bob doesn't own it there. She
can now make all the edits she wants. However, she won't be able to
replicate them to Bob's "foo", because she can't write there. She can
make a "foo-alice" db and give Bob read access, and he can merge from
there to his "foo" db. A lot like git.

==

I think if we ignore replication when thinking about node A's
configuration, we'll be much much more successful. Leaving replication
out of the story frees admins to use it how they see fit.

Imagine that node A is at the office, and they hire 500 people to a
new location, so now they have node A and node B. People in the new
office keep their databases on node B. IT wants to share credentials
and access controls across the two nodes, so they just setup
continuous replication on the users db - and done.

Chris


> - Since dbs are replicated, permissions on these dbs should be
> replicated too in a relatively untrusted environment.
>
> For now I see 2 possibilities :
>
> - one would be having couchdb node acting as provider : a user would
> be identified by its username and node hostname : user@nodehostename.
> Auuthentification is done on the provider hosting the user. Each db
> have a list of capababilities and owner:
>
> {
>   "_id" : "_acl/username",
>  "read": true,
>  "write": true,
>  "owner": true
> }
>
> An owner could set permissions of others users on a db. This process
> is similar to XMPP / Wave system but it imply that all nodes stay
> online to authenticate a user.
>
> - another possibility would be using a system of pub/private key. Each
> db have a list of users + their public key which would be replicated
> with the db :
>
> {
>   "_id" : "_acl/username",
>  "read": true,
>  "write": true,
>  "owner": true,
>  "key": publickey
> }
>
>
> ssl could be use for that. Each users connect to a database with its
> private key, and CouchDB get rights for this db. This process have one
> advantage compared to the one above because it allow to decentralize
> authentication. One other way to do it could be to store a secret key
> instead of using private/public key system but using ssl would allow
> any browser/http client to connect automatically and add some trust to
> the system. An admin could eventually revoke some users on its node
> etc.
>
> I would be for the last one to keep all the p2p replication system.
> Any other ideas? Damien how works the auth system on Notes ?
>
> - benoît
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message