On Tue, Sep 8, 2009 at 12:50 AM, Jason Davies<[email protected]> 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.
>
> 1. Where are the permission "objects" themselves stored? The permissions
> determine which users can do what with each database. I think storing these
> in the per-node users database (called "users" by default) makes the most
> sense. We are talking about per-db auth so it wouldn't make any sense to
> store this information in the affected databases themselves.
How would it work across replication ? I think across the couchdb
nodes the same set of users/authorizations in a db will be shared but
you don't always want to share the full `users` db.
I think we should differenciate node admins who can create the dbs and
inital users and users per db. After thinking about it I think having
users auths in the db with specific db admins could works (only admins
or some roles could changes rights).
>
> 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).
write only could be usefull to allow some bots to only put content.
Also maybe there is delete too ?
>
> 3. How do we implement these operations using the existing
> user_ctx{name=..., roles=[...]} object? I don't think we necessarily need
> to set any special roles, although this was my initial thought e.g.
> ['_read', '_write'] on a per-db basis. As authorization is a separate
> module, we can simply pass the appropriate permission (read and/or write)
> through when opening the db internally in the httpd db handler function.
> The db-opening function will then need to throw an error if writes are
> attempted and it is in read-only mode. Using actual roles is potentially
> more elegant, as custom roles could also be set using the permission objects
> and implementation might be easier.
I'm not sure to understand here. Where will be set rights for roles ?
an _auth/... document that would set roles maybe interrestings. Also
maybe set the matchings in it ?
>
> 4. One use-case we need to bear in mind is being able to grant/deny access
> to sets of databases at a time. One way to do this would be to allow
> patterns to be specified, for example:
>
> {
> "_id": "foo",
> "type": "permission",
> "username": "jason"
> "match": "jason/*",
> "operations": ["_read"]
> }
>
> This would grant the user "jason" read-only access to any database that has
> the prefix "jason/".
matching is good :) btw why operations are starting with a "_ " ?
>
> 5. Permissions per roles vs permissions per users? Although the above
> example specifies access for a particular user, it might be more elegant and
> efficient to do this per role instead. If per user is needed this can be
> done by giving the user a special role unique to them. If a user has
> multiple roles then we would take the union of the resulting permission set.
On a db level I don't think a user level is needed. Are you speaking
about doc ? Though, I would like to have a way to restrict on app
level. n users could access to an app, something like couch.it Public
: everyone can read/write / Private only logged can see, Semi-public
user need be logged to write. This could works for db too. Since one
app = one db generally, db level could be enough.
>
> 5. Default settings: we already have the require_valid_user setting, which
> forces a node to authenticate users. We would need to support certain
> access permissions for non-logged-in users i.e. anonymous users. This could
> be done using a special "_anonymous" string in the permission to override
> the default, which would probably be read/write for everyone as it is now.
>
> 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.
Using verbs seem logical. I think anyway it's a little too much to
have it by default. I would prefer to have a way to replicate auth
across nodes by default.
