couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pratt <fairwinds...@gmail.com>
Subject Re: Per Document Filtering/Authorization
Date Thu, 02 Dec 2010 17:00:45 GMT
Hi Chad. Let's dissect this with an example. Let's say you have a doc
with _type of  'vehicle'. If you want fine grained access for a
specific user, you do nothing on document other than identify _type
which is already something most folks do for filtering views etc. If
there is no entry in _authorization database, the data accessible to
the extent that we have any Readers for database as it is now.

If you want doc level authorization, you include a key with a special
name in _authorization database (much like we do with the _users
database). For the record that relates to vehicles, it contains an
_acl. You include any entry in the the _acl. For example. We can do
something like  [["Deny", "John"], ["Allow", "Salesman"]] which would
deny John record if he is user and go no further or [["Allow",
"John"], ["Deny", "Visitor"]] where John is given access specifically
where anyone with Role of Visitor is not allowed.

Personally, I believe the use case where you give a specific user
access to a particular document is less common that simply wanting
anyone with a specific role to access. That said, this is just as
simple with the acl approach. We already have the capability to
associate a user with a role with existing authorization scheme. So
for most part your acl is going to have more to do with Roles unless
you want to specifically deny someone as example above demonstrates.

There is nothing that increases issues with database portability here.
This is just an extension of existing approach. Obviously we would
want to bring _authorization database along just as we would _users.

There is no logic in the system other than a lookup similar to _users
where _authorization (or whatever it is named) is a special database
with no MVCC which results in a True or False evaluation of lookup to
determine access.

Along the line of authorization system we currently have, I think we
ought could possibly extend groups of users beyond Admins and Readers
so that there can be an implied capability to perhaps delete or modify
a doc. Right now it is more all or nothing.

Regards,
David


On Thu, Dec 2, 2010 at 9:45 AM, Chad George <chad@mgproducts.com> wrote:
> I'm not sure purely ACL based authorization is sufficient since it makes it
> difficult to authorize specific documents to specific users. A function that
> has access to both the request context (user) and document seems more
> flexible.
>
> Also, I'm not sure I see a benefit in having the security stuff in a
> separate database. It makes things more difficult to replicate an entire
> application since the logic would be split between two databases. Having the
> authorization functions defined on the design document seems simpler.
>
> - Chad
>
>
> On Wed, Dec 1, 2010 at 10:38 PM, David Pratt <fairwinds.dp@gmail.com> wrote:
>
>> A couple of small clarifications:
>>
>> > My thought is that we might wish to implement a special _authorization
>> > database (or give it some flexible name similar to _users) that is not
>> > under MVCC rules.
>>
>> To be clear, all I mean by this is that whatever we call the db, you
>> ought to be able to give it a different name in the configuration in
>> the same way you can with the _users database.
>>
>> > In this scenario, a key in the _authorization database corresponds to
>> > the _type. _authorization could use a naming convention to _users that
>> > makes it special.
>>
>> Sorry this should have read:
>> _authorization could use a similar naming convention to _users that
>> makes it special.
>>
>

Mime
View raw message