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