couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject CouchDB Authentication and Authorization
Date Thu, 25 Jun 2009 15:02:05 GMT
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
--


Mime
View raw message