couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From go canal <goca...@yahoo.com>
Subject Re: Application security model
Date Mon, 21 Dec 2009 00:29:39 GMT
somewhere you got to keep users' authorization information, inside or outside CouchDB. both
works. 
I think there are two types of actions:
 - what a user can do with existing documents (read, modify, delete)
   since this is for a specific document, we can have some attribute to indicate the permissions.
RBAC maybe one good choice. let's say, we have a Roles attribute with a list of roles permitted.
Then user-role mapping is stored somewhere.
 - for creating new documents
   Similarly, we need to keep this permission somewhere, if we follow the RBAC design above,
it seems to me that keeping the RBAC outside of CouchDB is a better choice:
    you can have RBAC info in a sql table. each user has one or more roles; each role has
permissions; then each document in CouchDB has a list of permitted roles.
   rgds,
canal




________________________________
From: Manuel Schölling <manuel.schoelling@gmx.de>
To: user@couchdb.apache.org
Sent: Sat, December 19, 2009 8:47:48 PM
Subject: Application security model

Hi there,

I'm just starting off with couch db.

There is something I'm wondering about: how should I implement the
authorization to access a document.

>From an outsider's view, one would use HTTP's authorization method when
using any PUT/GET/POST/DELETE requests.
But (as I understand it correctly) this mechanism is just available for
couch db administrator accounts.

So how should I implement a web application security layer?
Is there any panacea?

On could add a security field that includes ACL data to each document.
Then any update validation, view and list must check this data against a
user id and password that must be included in the REST request.

Or should you really create one couch db admin account for each user?
(I'm referring to a web application end-user here)


Cheers,

Manuel


      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message