couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dean Landolt" <d...@deanlandolt.com>
Subject Re: New Security and Validation Features
Date Fri, 21 Nov 2008 22:34:22 GMT
On Fri, Nov 21, 2008 at 5:12 PM, Damien Katz <damien@apache.org> wrote:

> 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



Beautiful. And dead simple.

I just have one question. What's this about:

    throw {forbidden, "All documents must have an author specified."}

Is that right? Is that an Erlangism intertwingled with javascript?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message