use case: replication of many databases, with/by many users

[svilen <az...@svilendobrev.com>]

g'day
this is about per-user authentication of replication. (similar to the
thread "App layer on top of replication" but that's not exactly my
use-case).

imagine a chat-room. each message is a document. each chat room is a
database. no conflicts. Each user can participate in many chat rooms
(=databases) and have them replicated to and from localy, continuosly
(on as many devices he wants).

the question is: how to make the authentication/security properly?

so far i'm guessing i should have a separate user-account layer/module
to know who is who on server. 

how to allow users to use only chat-rooms they're registered in?
in case all couchdb-user's credential live in database, and hence are
replicated, that is not usable.. 

how about replication itself? wrap it in some user-authenticated
api-call/url-rewrite (and disable it for external world)? or something
else?

ciao
svil

Re: use case: replication of many databases, with/by many users

[Dave Cottlehuber <dc...@jsonified.com>]

On 24 September 2012 06:00, svilen <az...@svilendobrev.com> wrote:
> i've been reading
>  http://wiki.apache.org/couchdb/Security_Features_Overview
>  http://wiki.apache.org/couchdb/Replication
> for a while, but some things inbetween them are missing.
>
> so after some trial-and-errors here's what i understand/assume so far:
>
> * couchdb users are per server-instance, in separate /_users db
> * an user can see/change only his /_users/id doc-profile (this
>   also means s/he can add hirself to any known/guessed role. hence
>   roles are not for guarding unauthorized use - but only for
>   specialization)

Yes, note you can use validation functions to enforce pretty much any
constraints you like, including deciding who can update roles.

> * databases can have /db/_security.readers.names as list of
> users allowed to read+write (or .admins for extra stuff)
> ** replication as plain http+read/write is under these permissions too
> - so cant replicate databases if unauthorized in them
> * only server-admins can create/delete a db
> * only db-or-server-admins can change db/_security
> * /db/_security is NOT replicated

I believe so, but I'm not sure how this security object is stored in
the .couch file.

> * /_users can be replicated manually

Yes. Again its just a normal DB so has the same replication
constraints you've noted.

> are these correct? especially the the /db/_security being
> non-replicable ? i could not make it replicate. If that is the case,
> then making *equal* copy of some database is not that
> straightforward - one has to manualy query+copy the _security object.
> repeat for each if there are many-many databases.

I think that's correct.

> so, if the couchdb user-authentication is to be used @ server, any
> create-db or add/del-user-to-db has to be made explicitly by some
> server-side app, before being usable. Or, if made locally, e.g. because
> no connection, (assuming u can do anything locally), they once there
> is connection, and the local db/changes is published to server, these
> have to be all re-played at server-side to actualy happen - i.e. create
> db, replicate data, then re-play add/del-user @ server to rebuild the
> db/_security.
>
> or am i missing something?
>
> ciao
> svilen

Yes. This is a fundamental constraint in _any_ distributed system -
for security there is only one instance you can trust - yourself. In
the infamous words of Lenin: "Trust is good, but control is better.".

In sharded systems the boundary of trust would need to be extended to
the cluster.

A+
Dave

Re: use case: replication of many databases, with/by many users

[svilen <az...@svilendobrev.com>]

i've been reading 
 http://wiki.apache.org/couchdb/Security_Features_Overview
 http://wiki.apache.org/couchdb/Replication
for a while, but some things inbetween them are missing. 

so after some trial-and-errors here's what i understand/assume so far:

* couchdb users are per server-instance, in separate /_users db
* an user can see/change only his /_users/id doc-profile (this
  also means s/he can add hirself to any known/guessed role. hence
  roles are not for guarding unauthorized use - but only for
  specialization)
* databases can have /db/_security.readers.names as list of
users allowed to read+write (or .admins for extra stuff)
** replication as plain http+read/write is under these permissions too
- so cant replicate databases if unauthorized in them
* only server-admins can create/delete a db
* only db-or-server-admins can change db/_security
* /db/_security is NOT replicated 
* /_users can be replicated manually

are these correct? especially the the /db/_security being
non-replicable ? i could not make it replicate. If that is the case,
then making *equal* copy of some database is not that
straightforward - one has to manualy query+copy the _security object.
repeat for each if there are many-many databases.

so, if the couchdb user-authentication is to be used @ server, any
create-db or add/del-user-to-db has to be made explicitly by some
server-side app, before being usable. Or, if made locally, e.g. because
no connection, (assuming u can do anything locally), they once there
is connection, and the local db/changes is published to server, these
have to be all re-played at server-side to actualy happen - i.e. create
db, replicate data, then re-play add/del-user @ server to rebuild the
db/_security.

or am i missing something?

ciao
svilen


On Tue, 18 Sep 2012 10:16:16 +0300
Ido Ran <id...@gmail.com> wrote:

> This solution will make the hub node a single point of failure and
> further make it either unable to use peer-to-peer or by using p2p you
> go around the security model and there is no good way to denied p2p
> replication. 
> 
> I'm also looking into the use case of database per topic replicated
> to each device and back so I'll be glad to see sound security model
> too. 
> 
> Ido 
> 
> 
>  
> > On 13 September 2012 08:17, svilen <az...@svilendobrev.com> wrote:
> >> g'day
> >> this is about per-user authentication of replication. (similar to
> >> the thread "App layer on top of replication" but that's not
> >> exactly my use-case).
> >> 
> >> imagine a chat-room. each message is a document. each chat room is
> >> a database. no conflicts. Each user can participate in many chat
> >> rooms (=databases) and have them replicated to and from localy,
> >> continuosly (on as many devices he wants).
> >> 
> >> the question is: how to make the authentication/security properly?
> >> 
> >> so far i'm guessing i should have a separate user-account
> >> layer/module to know who is who on server.
> >> 
> >> how to allow users to use only chat-rooms they're registered in?
> >> in case all couchdb-user's credential live in database, and hence
> >> are replicated, that is not usable..
> >> 
> >> how about replication itself? wrap it in some user-authenticated
> >> api-call/url-rewrite (and disable it for external world)? or
> >> something else?
> >> 
> >> ciao
> >> svil
> > 
> > Assuming you have a hub node that has all user accounts and a db per
> > chat room, that all external users replicate from/to, you could
> > simply use DB roles.
> > 
> > When you join a chat room, you'd need to be added to the role list
> > for that DB (by some process external to couch that knows if you are
> > allowed to access it), and then you could set up replication on the
> > endpoint node.
> > 
> > Would that be sufficient?
> > 
> > A+
> > Dave

Re: use case: replication of many databases, with/by many users

[Ido Ran <id...@gmail.com>]

This solution will make the hub node a single point of failure and further make it either unable to use peer-to-peer or by using p2p you go around the security model and there is no good way to denied p2p replication. 

I'm also looking into the use case of database per topic replicated to each device and back so I'll be glad to see sound security model too. 

Ido 



ב-13 בספט 2012, בשעה 17:13, Dave Cottlehuber <dc...@jsonified.com> כתב/ה:

> On 13 September 2012 08:17, svilen <az...@svilendobrev.com> wrote:
>> g'day
>> this is about per-user authentication of replication. (similar to the
>> thread "App layer on top of replication" but that's not exactly my
>> use-case).
>> 
>> imagine a chat-room. each message is a document. each chat room is a
>> database. no conflicts. Each user can participate in many chat rooms
>> (=databases) and have them replicated to and from localy, continuosly
>> (on as many devices he wants).
>> 
>> the question is: how to make the authentication/security properly?
>> 
>> so far i'm guessing i should have a separate user-account layer/module
>> to know who is who on server.
>> 
>> how to allow users to use only chat-rooms they're registered in?
>> in case all couchdb-user's credential live in database, and hence are
>> replicated, that is not usable..
>> 
>> how about replication itself? wrap it in some user-authenticated
>> api-call/url-rewrite (and disable it for external world)? or something
>> else?
>> 
>> ciao
>> svil
> 
> Assuming you have a hub node that has all user accounts and a db per
> chat room, that all external users replicate from/to, you could simply
> use DB roles.
> 
> When you join a chat room, you'd need to be added to the role list for
> that DB (by some process external to couch that knows if you are
> allowed to access it), and then you could set up replication on the
> endpoint node.
> 
> Would that be sufficient?
> 
> A+
> Dave

Re: use case: replication of many databases, with/by many users

[Dave Cottlehuber <dc...@jsonified.com>]

On 13 September 2012 08:17, svilen <az...@svilendobrev.com> wrote:
> g'day
> this is about per-user authentication of replication. (similar to the
> thread "App layer on top of replication" but that's not exactly my
> use-case).
>
> imagine a chat-room. each message is a document. each chat room is a
> database. no conflicts. Each user can participate in many chat rooms
> (=databases) and have them replicated to and from localy, continuosly
> (on as many devices he wants).
>
> the question is: how to make the authentication/security properly?
>
> so far i'm guessing i should have a separate user-account layer/module
> to know who is who on server.
>
> how to allow users to use only chat-rooms they're registered in?
> in case all couchdb-user's credential live in database, and hence are
> replicated, that is not usable..
>
> how about replication itself? wrap it in some user-authenticated
> api-call/url-rewrite (and disable it for external world)? or something
> else?
>
> ciao
> svil

Assuming you have a hub node that has all user accounts and a db per
chat room, that all external users replicate from/to, you could simply
use DB roles.

When you join a chat room, you'd need to be added to the role list for
that DB (by some process external to couch that knows if you are
allowed to access it), and then you could set up replication on the
endpoint node.

Would that be sufficient?

A+
Dave