auth per db - thoughts and question

[Benoit Chesneau <bc...@gmail.com>]

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
- 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

Re: auth per db - thoughts and question

[Benoit Chesneau <bc...@gmail.com>]

On Sun, Nov 1, 2009 at 11:04 PM, Chris Anderson <jc...@apache.org> wrote:
> On Sun, Nov 1, 2009 at 1:25 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>> Anyway that may be a feature for 0.11 ? I could work on it quietly.
>> For now I found an alternative to that for my service.
>>
>
> I think the most important aspect here is the Accounts tab for Futon.
> This is key to making it super-simple for people to write user-based
> apps on CouchDB. If they don't have to write the login code, it
> becomes much much easier to get started.
>
that's just ui. Imo the most important thing is to have real
authentification. Currently there isn't nothing like. There is a need
to forbid people to read content of database or even to read some docs
without having a proxy. I could understand that having an interface to
manage accounts could help but then accounts should be useful too.

- benoit

Re: auth per db - thoughts and question

[Chris Anderson <jc...@apache.org>]

On Sun, Nov 1, 2009 at 1:25 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>
> Anyway that may be a feature for 0.11 ? I could work on it quietly.
> For now I found an alternative to that for my service.
>

I think the most important aspect here is the Accounts tab for Futon.
This is key to making it super-simple for people to write user-based
apps on CouchDB. If they don't have to write the login code, it
becomes much much easier to get started.

Chris

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

Re: auth per db - thoughts and question

[Benoit Chesneau <bc...@gmail.com>]

On Sun, Nov 1, 2009 at 7:59 PM, Chris Anderson <jc...@apache.org> wrote:
> On Sun, Nov 1, 2009 at 3:33 AM, Benoit Chesneau <bc...@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'm agree with this process, this is simple. But still git contain
user "signature" with email and sometimes also the gpg signature so
you can continue to track access/merge/branching whatever.

>
> ==
>
> 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
>
>
This schema works only in a trusted environment, doesn't it ?. I would
like to be able to only share users / db rather than a whole db. A
pub/private system would allow it, and also would allow later to have
a way to follow documents/users imo. Anyway right step by step, and
your schema above allow already the replication if one user allow read
access  exceot maybe for ddocs maybe.


Anyway that may be a feature for 0.11 ? I could work on it quietly.
For now I found an alternative to that for my service.

- benoit

Re: auth per db - thoughts and question

[Chris Anderson <jc...@apache.org>]

On Sun, Nov 1, 2009 at 3:33 AM, Benoit Chesneau <bc...@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