On Sep 7, 2009, at 5:50 PM, Jason Davies wrote:
Hi all,
There have been sporadic discussions about various granularities of
authorization. The most simple level to tackle is per-db
authorization. What follows is a summary of discussions and ideas
so far.
I should point out that this is primarily to flesh out the default
authorization modules that address the needs of the majority of
users. We probably will have an authorization_handlers settings,
analagous to authentication_handlers, allowing custom authorization
modules to be used.
I think it would be common for there to be a fairly high
initialization cost in loading and preprocessing authorization data
for more complex authorization schemes, so you'd want something like
the gen_server behavior and message passing on authorization for the
generic authorization hook.
2. What types of operations do we need to support? I think the
majority of users will only care about being able to make particular
databases read-only, read/write, or write-only (not sure about the
latter one).
As long as the authorization hooks are generic enough to support
content-aware authorization, I'm not particularly concerned with the
details of a specific authorization module. My main concern is that
the hooks might be designed only to meet the needs of a specific
authorization module and would not be able to handle more generic cases.
6. Future work: thisfred suggested that the pattern-matching could
be extended to the full URL instead of just the database name. This
seems like a simple way to extend authorization. Of course, it's
dependent on a particular node's URL mappings (these can be changed
in the .ini). This then brings up the question of what the
operations should be, it would make the most sense to let them be
HTTP verbs, so that one could restrict access to certain URLs to
being only GET and HEAD for example. This seems a bit too tied to
HTTP for my liking, but I guess CouchDB is very much a RESTful and
therefore HTTP-reliant database. Any further ideas would be welcomed.
I'd like to see call outs to authorization in couch_db around any read
or write to the underlying store. If the authorization is HTTP
request based, then to restrict access to particular piece of info,
you need to restrict the document GET, any queries or lists might
reveal the info, etc. Then if some later version of CouchDB adds a
new http request, previously controlled might be exposed. I do
believe it is valuable to be able to restrict particular http request
methods, but it isn't sufficient.
On Sep 8, 2009, at 5:41 PM, Adam Kocoloski wrote:
So, after giving this some thought I'm partial to the idea of Access
Control Lists. Instead of directly granting privileges on databases
in the users DB, we'd store an ordered list in the DB in a special
document that would allow|deny requests that match a rule. For
instance, if I wanted to make a read-only DB where only I could
access the _design documents I could upload a document like
{
_id: "_authorization",
_rev: "1-1340514305943",
_acl: [
{"access":"allow", "role":"kocolosk", "method":"*",
"path":"*"},
{"access":"deny", "role":"*", "method":"*",
"path":"_design*"}
{"access":"allow", "role":"*", "method":"GET",
"path":"*"},
{"access":"deny", "role":"*", "method":"*",
"path":"*"}
]
}
The rules in the ACL array are applied in order, and the first rule
to match wins. Here I've assumed that my user has a corresponding
role, like a UNIX group.
I explicitly listed the deny rule at the end, but we could make that
the default if we wished. CouchDB has historically been pretty
open, but sysadmins would probably prefer it if things were secure
out-of-the-box. I think the right default setting will become clear
during the implementation.
I was thinking that a transliteration of XACML to JSON would be a good
approach (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#XACML20
).
