On Sat, Feb 6, 2010 at 1:58 AM, Brian Candler <[email protected]> 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'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
