incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Per-DB Auth Ideas and Proposal
Date Tue, 08 Sep 2009 20:30:47 GMT
On Tue, Sep 8, 2009 at 12:50 AM, Jason Davies<jason@jasondavies.com> 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.

Mime
View raw message