couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: CouchDB Authentication and Authorization
Date Thu, 25 Jun 2009 19:49:23 GMT
2009/6/25 Jan Lehnardt <jan@apache.org>:
> Hey Couchers,
>
> I'd like to add OAuth support to CouchDB. In thinking about how to make
> a oauth_authentication_handler much like Jason's
> cookie_authentication_handler
> I went a little further and see how this would fit into a more fine grained
> authentication and authorization system for CouchDB.
>
> I'd like to get my work in progress out here to get your feedback and
> guidance.
> I'm not married to any of the nomenclature, so feel free to suggest
> alternatives
> along the way.
>
> OAuth won't need all of that is outlined here, but it would use the
> foundations of
> this system, and I'd like to get that right from the get go.
>
> Your input is highly appreciated, thanks!
>
> --
>
> # CouchDB Authentication and Authorization
>
> This document describes a potential CouchDB authentication and authorization
> system.
>
>
> ## Authentication
>
> An HTTP request can contain credentials that identify a user in numerous
> ways. The authentication mechanism should treat HTTP basic authentication,
> cookie authentication, OAuth or any other future system transparently.
>
>
> ## The Authentication Database
>
> CouchDB will use a `users` database (the authentication database) to
> authenticate users. User credentials must identify a user uniquely. A
> username / password combination must point to a single user. An OAuth token
> must identify a single user.
>
> The authentication database contains documents identified by UUIDs.
> Authentication handlers (see below) create views on the authentication
> database to look up a user for a given credential.
>
> The request record that gets passed around the CouchDB internals carries the
> user's id after the user successfully authenticated.
>
>
> ## Authentication Handlers
>
> An authentication handler is an Erlang module that takes authenticates a
> user given handler-specific authentication data. A handler installs a view
> in the authentication database to look up user ids by login credentials that
> come in with a request.
>
> A an example authentication client request
>
>  | client |  ---> | http request with credentials |  ---> | authentication
> handler |  ---> | lookup in authentication handler specific view in `users`
> database |  ---> | grant or deny access, set role |
>
>
> ### The Default Authentication Handler
>
> The default authentication handler creates a view
> `_design/default/_view/by-credential` to to look up `login` for a given
> request.
>
>
> ### The Cookie Authentication Handler
>
> The cookie authentication handler creates a view
> `_design/cooie/_view/by-credential` to to look up `request_token` for a
> given request.
>
>
> ### The OAuth Authentication Handler
>
> The OAuth authentication handler creates a view
> `_design/cooie/_view/by-credential` to to look up `request_token` for a
> given request.
>
>
> ## Authorization
>
> Each database contains a set of `_user/userid` documents. Roles documents
> include an array of roles for a given user:
>
>    {
>      _id: "_user/123ccadd254",
>      _rev: "1-74474398",
>      roles: ["owner"]
>    }
>
> The `roles` array can include `"owner"`, `"writer"` and `"reader"`.
>
>
> ### Database Owners
>
> Database owners can create, edit and delete `_design/` and `_user/` docs as
> well as creating, reading, updating and deleting regular documents.
>
>
> ### Database Writers
>
> Database writers can only create, read, update and delete regular documents.
>
>
> ### Database Readers
>
> Database readers can only read documents.
>
>
> ### Anonymous Users
>
> An anonymous user gets identified with the id `_anonymous`. If the
> `_user/_anonymous` document includes the role `"guest"`, anonymous users can
> create, read, update and delete regular documents.
>
> If the `_user/_anonymous` document includes the role `"owner"`, anonymous
> users can create, read, update and delete `_design` documents as well as
> regular documents.
>
>
> ### `_user/` Document and Replication
>
> `_user/` documents do not replicate by default. A replication trigger option
> replicates them:
>
>    POST /_replication HTTP/1.1
>    {"source":"db","target":"db-replica":"include_role_docs":true}
>
>
> ## Recommendations
>
> User specific data like an avatar picture should live in the authentication
> database.
>
> Application-specific user-data should live in regular documents managed by
> the application and *not* `_user/` documents.
>
> --
>
> Cheers
> Jan
> --
>
>

That sound good for me except for the anonymous stuff and user
specific data. Why not keeping same roles as other and just specify
writer when you want to allow write for guests ?

About the user specific data I'm a little afraid about security. I
think user database should be protected for all users except admins.
Sure password is hashed/encrypted but this is just a question of
time/number of cpu that some could decrypt these password. I would
prefer them not so easyly available. So maybe user profiles & co could
be in an optionnal  "profile" db. This for case when you expose
database to the public. Maybe it's a little paranoid though.

Btw wil you use the current erlang oauth module to do that ?

- benoit

Mime
View raw message