On Fri, Nov 21, 2008 at 5:12 PM, Damien Katz <[EMAIL PROTECTED]> 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?
