incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paweł Stawicki <pawelstawi...@gmail.com>
Subject Re: Application security model
Date Mon, 21 Dec 2009 07:48:01 GMT
What I need, is right at database level. I don't want to put
permissions on every document, but for database. Is it possible?

Best regards
-- 
Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl
http://www.java4people.com

On Mon, Dec 21, 2009 at 01:29, go canal <gocanal@yahoo.com> wrote:
> 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)

Mime
View raw message