Document Security Design Question

[Ryan Ramage <ry...@gmail.com>]

I have a couch app that I am building that now I have to start
thinking about security. I will have documents that I need to restrict
access to by users. So for a given document I have a set of users that
can access the document, and a set that can't.

Another condition of this scenario is the documents will have a large
attachments with them, so I am trying to keep replication down to a
minimum.

Since couch db does not support fine grained readers in one db, I had
the idea to create a separate db which has a sole purpose of holding
the document. Then I would define the readers list for that db to the
set of users.

The issue I have is that when the time comes to create the document
(and associated db), the user that will do it will not be a server
admin. It will be the main user who is creating the document. I don't
have a middleware layer, and I cant think of another way to do this.
The only other way I can see is to have a user based db, and when a
user commits a doc to it, it replicates to all other user with
permissions, but I really don't want to be replicating the large
attachments (that need to stay with the doc)...

Anyone have thoughts on this?

Re: Document Security Design Question

[Ryan Ramage <ry...@gmail.com>]

Sorry, in my example I failed to mention the documents I am referring
to are not couch docs but a higher level document There will be plenty
of couch level docs stored in the main db. But it is only for one
particular type of high level doc would be stored in the separate db.
These ones need that per doc auth.

Again in my use case, I am trying to prevent even filtered replication
because of overhead due to the attachment size.

The proxy control could work, but I am trying to keep it like 'couch
app' with the idea that there is a low overhead to install.

I know, I am restricting the possibilities.

All I can see is either
1) somewhere to change what only a server admin can do (ACL?)
or
2) Have some way to access server admin functions inside a show function.

Are any of these possible?

On Tue, Aug 10, 2010 at 12:05 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 11 August 2010 05:47, Ryan Ramage <ry...@gmail.com> wrote:
>> I have a couch app that I am building that now I have to start
>> thinking about security. I will have documents that I need to restrict
>> access to by users. So for a given document I have a set of users that
>> can access the document, and a set that can't.
>>
>> Another condition of this scenario is the documents will have a large
>> attachments with them, so I am trying to keep replication down to a
>> minimum.
>>
>> Since couch db does not support fine grained readers in one db, I had
>> the idea to create a separate db which has a sole purpose of holding
>> the document. Then I would define the readers list for that db to the
>> set of users.
>>
>> The issue I have is that when the time comes to create the document
>> (and associated db), the user that will do it will not be a server
>> admin. It will be the main user who is creating the document. I don't
>> have a middleware layer, and I cant think of another way to do this.
>> The only other way I can see is to have a user based db, and when a
>> user commits a doc to it, it replicates to all other user with
>> permissions, but I really don't want to be replicating the large
>> attachments (that need to stay with the doc)...
>>
>> Anyone have thoughts on this?
>>
>
> a DB per doc seems overkill, you might as well store them directly on
> a filesystem & serve up directly.
>
> A better approach might be to have a master set of couches which hold
> all data for all users, and then allow via filtered replication &
> validation functions only docs that are tagged for your
> user/group/function to filter to each local couch. You would then need
> an additional method of controlling access to the master DB data,
> perhaps either a proxy setup to prevent direct URL access for users,
> or get the proxy to do authentication & control.
>
> I am sure somebody's already got a design pattern for this.
>
> cheers
> Dave
>

Re: Document Security Design Question

[Dave Cottlehuber <da...@muse.net.nz>]

On 11 August 2010 05:47, Ryan Ramage <ry...@gmail.com> wrote:
> I have a couch app that I am building that now I have to start
> thinking about security. I will have documents that I need to restrict
> access to by users. So for a given document I have a set of users that
> can access the document, and a set that can't.
>
> Another condition of this scenario is the documents will have a large
> attachments with them, so I am trying to keep replication down to a
> minimum.
>
> Since couch db does not support fine grained readers in one db, I had
> the idea to create a separate db which has a sole purpose of holding
> the document. Then I would define the readers list for that db to the
> set of users.
>
> The issue I have is that when the time comes to create the document
> (and associated db), the user that will do it will not be a server
> admin. It will be the main user who is creating the document. I don't
> have a middleware layer, and I cant think of another way to do this.
> The only other way I can see is to have a user based db, and when a
> user commits a doc to it, it replicates to all other user with
> permissions, but I really don't want to be replicating the large
> attachments (that need to stay with the doc)...
>
> Anyone have thoughts on this?
>

a DB per doc seems overkill, you might as well store them directly on
a filesystem & serve up directly.

A better approach might be to have a master set of couches which hold
all data for all users, and then allow via filtered replication &
validation functions only docs that are tagged for your
user/group/function to filter to each local couch. You would then need
an additional method of controlling access to the master DB data,
perhaps either a proxy setup to prevent direct URL access for users,
or get the proxy to do authentication & control.

I am sure somebody's already got a design pattern for this.

cheers
Dave