You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Manuel Schölling <ma...@gmx.de> on 2009/12/19 13:47:48 UTC
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
Re: Application security model
Posted by Paweł Stawicki <pa...@gmail.com>.
I think there should be one user for whole web application. But how to
give him rights only to one db? I would also like to know.
Regards
--
Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl
http://www.java4people.com
Re: Application security model
Posted by go canal <go...@yahoo.com>.
I am afraid that it is not supported in CouchDB for now;
rgds,
canal
________________________________
From: Paweł Stawicki <pa...@gmail.com>
To: user@couchdb.apache.org
Sent: Mon, December 21, 2009 3:48:01 PM
Subject: Re: Application security model
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 <go...@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 <ma...@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)
Re: Application security model
Posted by Paweł Stawicki <pa...@gmail.com>.
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 <go...@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 <ma...@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)
Re: Application security model
Posted by go canal <go...@yahoo.com>.
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 <ma...@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