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
--

Reply via email to