couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject New Security and Validation Features
Date Fri, 21 Nov 2008 22:12:51 GMT
Here is brief outline of the new security and validation stuff.

-Authentication, batteries not included-

Currently CouchDB contains no general authentication modules, but does  
allow for plug-in authentication modules via setting in the ini.

The test suite uses a special test authentication module, with  
hardcoded names and passwords and simple protocol with everything sent  
cleartext. It can serve as an example and starting point for building  
real authentication modules, like modules that connect to external  
LDAP or Active Directory servers.

Eventually we'll include a built-in authentication module that uses an  
internal CouchDB database for user accounts.

The authentication module, upon successful authentication, returns a  
user context object that has the user's name and list of roles, and  
perhaps more meta information about the user. This context object is  
then later used in validation of updates of both design and regular  

The list of roles for a user would be something like ["Engineer",  
"Party Planning Committee", "Discussion Moderator"].

-Server and DB Admins-

If the authentication module gives the user the role of "_admin", they  
are given server wide admin access. Server admins can create and  
delete databases, and set the individual DB admins and update design  
documents. (By default, until admin accounts are turned, all users are  

Each database has an DB Admins list. It's a simple list of user names  
and roles that are allow administrator access to the database. If a  
user's name or a role appear in the DB Admins list, then that user is  
a DB Admin. The DB Admins, along with Server Admins, are allowed to  
change the DB Admins list, to add or remove admin access for others,  
or remove admin access for themselves. Server Admins are automatically  
DB Admins. Also, design documents can only be created/updated by admins.

The admin list  be should relatively small, it's kept in memory.

I'm thinking the ability to create temp view should be restricted to  
admins as well, or at least configurable as such. Currently anyone can  
make temp view queries.


Each design document can contain a document update validation  
function. Like views, these can be in any language. The language is  
set at the design document level.

On document update -- either via interactive update or via replication  
-- each is run in succession. These validation functions are  
responsible for enforcing document constraints or schemas, and to  
enforce security.

Validation functions are provided the new document, previous revision  
of the document on disk, and the user context. The user context has  
the users name and roles.

If the document values don't pass validation, a forbidden exception is  
returned If the user isn't allow to update the document, a  
unauthorized exception is returned.

This scheme can be used for signature based security (is the update  
signed by an authorized user) or user based security (is the user  
currently writing the update an authorized user).

This user based example ensures that every document has an authors  
field and when updating an existing document, you are an allowed  
author, or a moderator:

function(newDocument, previousDocument, userCtx) {
   if (!newDocument._deleted && ! {
	throw {forbidden, "All documents must have an author specified."}
   if (previousDocument && != &&
	userCtx.roles.indexOf("Discussion Moderator") == -1) {
  	throw {unauthorized, "You are not the author of this document."}

The validation works with replication too, all updates, whether  
interactive or replicated are validated. But the replication still  
needs testing and might be buggy on update failures.

That's all for now. Question and comments please.


View raw message