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