incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Fischer <robert.fisc...@smokejumperit.com>
Subject Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Date Wed, 02 Jul 2008 18:13:05 GMT
Two points.

1) I'd encourage the CouchDB group to stick to authorization and leave authentication to proxies
at
this point.  If you have some free time in the future, maybe you can think about integrating
an
authentication layer -- but there's a lot more critical functionality needed, and an HTTP
proxy can
handle it just fine for the time being.  If you consider that username/password authentication
is
inherently evil, and "real" authentication servers are built off of LDAP, kerberos, or the
like,
then the massive amount of work involved in doing authentication should be clear.  And this
isn't
even getting into the likelihood that a new authentication implementation will probably get
some
stuff wrong in non-trivial, non-obvious ways.  So, please, let authentication be handled by
proxies.

2) In terms of authorization, it would be nice if there was a concept of "read only" and
"read-write" premissions at the database level.  MySQL goes a bit nuts with their permissions
possibly going all the way down to the column level, but it's nice to have that distinction
at the
database level.  This means I can guaranty I don't accidentally modify something when I just
mean to
be querying it: this kind of functionality has saved my butt a number of times in the past
("Why is
this update failing on my dev box?  Oh...wait...that's my production terminal window!"), and
it
would be sad to see it left out.

Of course, I could do that kind of permission setting at the Apache level, too, by defining
the
routes as locations and setting permissions -- but it'd probably be both cleaner and more
appropriate to be done in the DB itself.

~~ Robert.

Noah Slater wrote:
> Perhaps we could rely on standard HTTP auth either:
> 
>  * as passed back through a proxy
>  * as negotiated by CouchDB using a similar method to Apache httpd
> 
> This doesn't seem too hard, Mochiweb might even support it natively.
> 
> On Wed, Jul 02, 2008 at 12:56:44PM -0400, Damien Katz wrote:
>> We need to implement a couchdb security model. I think at a high level
>> it should be simple as possible. Also I think we won't do
>> authentication, that should be handled by a authenticating proxy, or
>> application code.
>>
>> I'm thinking our model looks something like this:
>>
>> We'll have server wide admin accounts, and dbadmin accounts. Db Admins
>> can create dbs and admin their own dbs. Server admins are like
>> superusers. Only admins are allowed to update design documents in
>> databases.
>>
>> The per-database customized module will be supported by custom
>> validation functions contained in databases design documents.  When a
>> document is updated, either via replication or new edit, these
>> validation functions are evaluate with provided context.
>>
>> Here is a very simplistic validation routine:
>>
>> function (doc, ctx) {
>>       if (doc.type == "topic" && doc.subject == undefined) {
>>               throw "Error, a subject is required for all topics.";
>>       }
>> }
>>
>> Something that looks at previous revisions:
>>
>> function (doc, ctx) {
>>       var prev = ctx.get_local_doc();
>>       if (prev != null && prev.author != ctx.user_name()) {
>>               throw "Error, update by non-author.";
>>       }
>> }
>>
>> It should also be possible modify the document while it's being saved,
>> but this might only be allowable when its a new edit, vs a replicated
>> update or backup restore.
>>
>> All further security schemes would be handled the customized functions,
>> and though APIs to do database or external ldap queries.
>> On Jul 2, 2008, at 3:08 AM, Jan Lehnardt wrote:
>>
>>> Hello everybody,
>>> this thread is meant to collect missing work items (features and
>>> bugs) for for our 1.0 release and a discussion about how to split
>>> them up between 0.9 and 1.0.
>>>
>>> Take it away: Damien.
>>>
>>> Cheers
>>> Jan
>>> --
> 

Mime
View raw message