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
documents.
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
admins)
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.
-Authorization/Validation-
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 && !newDocument.author) {
throw {forbidden, "All documents must have an author specified."}
}
if (previousDocument &&
previousDocument.author != userCtx.name &&
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.
-Damien
