You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Damien Katz <da...@gmail.com> on 2008/07/02 18:56:44 UTC
Security and Validation - Re: CouchDB 0.9 and 1.0
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
> --
Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Posted by David Pitman <me...@davidpitman.name>.
Thanks for your thoughts there, I'll definitely keep that in mind!
Personally I find the mySQL model overly annoying too, but I thought it was
a good place to start since it's "popular". OK, well maybe not then :) ...
If you (or anyone here) knows of a database whose security model they DO
like, then feel free to post it here so I can take a look at that for
further inspiration ...
Thanks again and I will certainly be posting my results when I have
something that seems worthwhile.
David.
On Mon, Jul 7, 2008 at 6:16 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Disclaimer: It is Monday, I overslept and haven't had coffee yet. If I
> sound
> overly grupmy, that is the reason :)
>
> On Jul 7, 2008, at 05:29, David Pitman wrote:
>
> Just to let you know that I have been working on an "out-of-the-box
>> solution
>> for 1)" for a few weeks (in my spare time), mainly at this stage mapping
>> out
>> various schemes for how this could work and learning more about other
>> databases' authentication frameworks. I figure if it is conceptually
>> similar (as far as convenient) to existing authentication frameworks such
>> as
>> what's used by mySQL, then developers will have an even easier learning
>> curve and find CouchDB yet more attractive.
>>
>
> Please do _NOT_ model a security model after the MySQL security model.
> There are so many things wrong with it that I don't even know where to
> begin. Well, maybe, it is not that bad, but it is not easy to use and as
> a result everybody implements their own security custom scheme on top of
> MySQL and as a result, shared hosters give out only single MySQL accounts,
> because that's what everybody needs and as a direct result you can't share
> or
> move a userbase between two applications because, well, they have their
> own system. And as a bonus point: All security systems need to do the same
> thing over and over again and will introduce the same bugs over and over
> again.
>
> I don't want that happen to CouchDB :) It would be nice if CouchDB's
> security
> system would be exposed to a user & application for usage so they have a
> framework to do logins and permissions that all CouchDB applications can
> share. To avoid a) duplication of effort by writing yet another user
> management
> and permission system b) introduction of another two billion security
> systems
> that all have one bug or another and c) having to maintain two separate for
> two separate applications which is either a PITA for the user or admin.
>
> Yes out of the box would be nice, yes LDAP and other backends should be
> puginnable and yes this involves a lot of work and that's why we (at least
> I)
> want to keep that off 1.0.
>
>
> At the moment I'm prototyping in php and c++ (fast and easy), but once I've
>> established how I want it to work, I'm planning to start working with
>> Erlang
>> (I'm new to that). I'll post up some details of my ideas once I've got a
>> nice fleshed-out concept that seems to work for me nicely.
>>
>> I'm thinking of a kind of "out-of-the-box" plugin to the CouchDB which
>> adds
>> in the authentication layer, but which is not required by CouchDB to work.
>> Will let people know more when I've got something useful to show for my
>> efforts ...
>>
>
> Ignoring the above: It would be really nice to see what you come up with
> here,
> please share your results :)
>
> Cheers
> Jan
> --
>
>
>
>>
>> Thanks.
>>
>> David.
>>
>> On Thu, Jul 3, 2008 at 6:47 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>
>>> On Jul 2, 2008, at 20:13, Robert Fischer wrote:
>>>
>>> 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.
>>>>
>>>>
>>> +1 on both accounts.
>>>
>>> For the long term, it'd be nice to have an out-of-the-box
>>> solution for 1), but we shouldn't focus on this now.
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>>
>>>
>>>
>>>
>>>> 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
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> David Pitman
>> www.davidpitman.name
>>
>
>
--
David Pitman
www.davidpitman.name
Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Posted by Jan Lehnardt <ja...@apache.org>.
Disclaimer: It is Monday, I overslept and haven't had coffee yet. If I
sound
overly grupmy, that is the reason :)
On Jul 7, 2008, at 05:29, David Pitman wrote:
> Just to let you know that I have been working on an "out-of-the-box
> solution
> for 1)" for a few weeks (in my spare time), mainly at this stage
> mapping out
> various schemes for how this could work and learning more about other
> databases' authentication frameworks. I figure if it is conceptually
> similar (as far as convenient) to existing authentication frameworks
> such as
> what's used by mySQL, then developers will have an even easier
> learning
> curve and find CouchDB yet more attractive.
Please do _NOT_ model a security model after the MySQL security model.
There are so many things wrong with it that I don't even know where to
begin. Well, maybe, it is not that bad, but it is not easy to use and as
a result everybody implements their own security custom scheme on top of
MySQL and as a result, shared hosters give out only single MySQL
accounts,
because that's what everybody needs and as a direct result you can't
share or
move a userbase between two applications because, well, they have their
own system. And as a bonus point: All security systems need to do the
same
thing over and over again and will introduce the same bugs over and
over again.
I don't want that happen to CouchDB :) It would be nice if CouchDB's
security
system would be exposed to a user & application for usage so they have a
framework to do logins and permissions that all CouchDB applications can
share. To avoid a) duplication of effort by writing yet another user
management
and permission system b) introduction of another two billion security
systems
that all have one bug or another and c) having to maintain two
separate for
two separate applications which is either a PITA for the user or admin.
Yes out of the box would be nice, yes LDAP and other backends should be
puginnable and yes this involves a lot of work and that's why we (at
least I)
want to keep that off 1.0.
> At the moment I'm prototyping in php and c++ (fast and easy), but
> once I've
> established how I want it to work, I'm planning to start working
> with Erlang
> (I'm new to that). I'll post up some details of my ideas once I've
> got a
> nice fleshed-out concept that seems to work for me nicely.
>
> I'm thinking of a kind of "out-of-the-box" plugin to the CouchDB
> which adds
> in the authentication layer, but which is not required by CouchDB to
> work.
> Will let people know more when I've got something useful to show for
> my
> efforts ...
Ignoring the above: It would be really nice to see what you come up
with here,
please share your results :)
Cheers
Jan
--
>
>
> Thanks.
>
> David.
>
> On Thu, Jul 3, 2008 at 6:47 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Jul 2, 2008, at 20:13, Robert Fischer wrote:
>>
>> 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.
>>>
>>
>> +1 on both accounts.
>>
>> For the long term, it'd be nice to have an out-of-the-box
>> solution for 1), but we shouldn't focus on this now.
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
>>
>>>
>>> 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
>>>>>> --
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> David Pitman
> www.davidpitman.name
Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Posted by David Pitman <me...@davidpitman.name>.
Just to let you know that I have been working on an "out-of-the-box solution
for 1)" for a few weeks (in my spare time), mainly at this stage mapping out
various schemes for how this could work and learning more about other
databases' authentication frameworks. I figure if it is conceptually
similar (as far as convenient) to existing authentication frameworks such as
what's used by mySQL, then developers will have an even easier learning
curve and find CouchDB yet more attractive.
At the moment I'm prototyping in php and c++ (fast and easy), but once I've
established how I want it to work, I'm planning to start working with Erlang
(I'm new to that). I'll post up some details of my ideas once I've got a
nice fleshed-out concept that seems to work for me nicely.
I'm thinking of a kind of "out-of-the-box" plugin to the CouchDB which adds
in the authentication layer, but which is not required by CouchDB to work.
Will let people know more when I've got something useful to show for my
efforts ...
Thanks.
David.
On Thu, Jul 3, 2008 at 6:47 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jul 2, 2008, at 20:13, Robert Fischer wrote:
>
> 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.
>>
>
> +1 on both accounts.
>
> For the long term, it'd be nice to have an out-of-the-box
> solution for 1), but we shouldn't focus on this now.
>
> Cheers
> Jan
> --
>
>
>
>
>>
>> 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
>>>>> --
>>>>>
>>>>
>>>
>>
>
--
David Pitman
www.davidpitman.name
Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 2, 2008, at 20:13, Robert Fischer wrote:
> 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.
+1 on both accounts.
For the long term, it'd be nice to have an out-of-the-box
solution for 1), but we shouldn't focus on this now.
Cheers
Jan
--
>
>
> 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
>>>> --
>>
>
Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Posted by Robert Fischer <ro...@smokejumperit.com>.
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
>>> --
>
Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Posted by Noah Slater <ns...@apache.org>.
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
>> --
>
--
Noah Slater, http://people.apache.org/~nslater/