I agree with Jan. The goal should be to achieve the best design possible at this point. (Not saying Brian's idea is better that what Chris has committed because I don't have the knowledge to really know either way.) The point is authorization is a really important "feature" and we shouldn't really be worrying about existing client libraries prior to a 1.0 release imho. Getting it right is much more important. I am starting to get concerned about the current plans regarding authorization and releasing 1.0, but I guess I should reply to Damien's thread about that.
James Hayton -----Original Message----- From: Jan Lehnardt [mailto:j...@apache.org] Sent: Saturday, February 06, 2010 11:38 AM To: dev@couchdb.apache.org Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0) On 6 Feb 2010, at 10:52, Chris Anderson wrote: > On Sat, Feb 6, 2010 at 1:58 AM, Brian Candler <b.cand...@pobox.com> wrote: >> A thought. >> >> The current security model requires you spread information in three places: >> _readers (has access to database); _security (for controlling updates); >> _admins (can update security and ddocs) >> >> What if this was replaced by a single resource, _security, structured like >> this? >> >> { >> "names":{ >> "foo":[], >> "bar":["_admin"] >> }, >> "roles":{ >> "baz":["doctor"] >> } >> "otherstuff" >> } >> >> You get reader access if your name or role appears as key in the relevant >> section, regardless of the value. So [] means reader only. You get admin >> access if the value contains "_admin". Other rights are available for the >> application to use, and may affect validate_doc_update. >> >> The reasons I propose this are as follows: >> >> 1. it's extensible without having to change the DB structure again >> 2. application-specific rights can be administered in the same way as >> couchdb system rights >> 3. futon can display this clearly - a list of names and a list of roles, >> each with their rights shown next to it >> 4. a hash key is quicker to look up for access control than an array scan >> >> However it retains the current fundamental design, which is that the rights >> are stored in a resource within the database, which is not a document. >> >> Thoughts? >> >> What I've really done is to flip things around, so that >> >> "readers":["name1","name2"] >> "admins":["name3"] >> >> becomes >> >> {"name1":["reader"], "name2":["reader"], "name3":["admin"]} >> >> But doing that also makes it easier to add a future auth model where rights >> are stored in a more scalable way (e.g. as separate user documents or in an >> external LDAP database), where such information is keyed by username or >> role. > > I'm curious how this model supports the common case of a publicly > accessible database with administrators? > > As far as replacing the _admins _readers and _security database values > with single complex value, the only reason I didn't do that is that we > already have a bunch of client libraries that know about _admins. The > underlying storage treats it all as one object. I don't think it > matters either way, but I lean toward the status quo because that is > code that has already been written. I think this notion is dangerous. If we can opt for a better design, now is the time to do it. Cheers Jan -- > > I'd be pretty surprised if the ACLs that ship with 0.11 are > significantly different from what I committed last week. > > Can you explain your application needs? I'm pretty sure that the > current ACLs can support them. But if you have a common use case falls > out side what can be done with readers / admins / validations, maybe > there are minimal tweaks we can do to make it easier for you. > > Chris > >> >> Regards, >> >> Brian. >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io
