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 <[email protected]> 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 <[email protected]> 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
