couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Auth Roadmap
Date Thu, 11 Feb 2010 12:20:35 GMT
> I think what you say has merit, but it doesn't jibe with my
> understanding of our implementation in a logical way. I'm ready to
> ship the basic programming model we have - it maps cleanly onto the
> underlying infrastructure (less abstraction can be a good thing).

With respect, I think we're actually talking about the same thing :-)

You've already said that it may make sense to lump _readers and _admins into
_security. If so, then I think this is what you would get:

  {
    "_readers":{
      "names":["foo","bar"],
      "roles":["baz"]
    },
    "_admins":{
      "names":["jan","brian"],
      "roles":["support"]
    },
    "other_security_stuff":{...}
  }

You've also suggested adding some more granular capabilities, such as
_replicators and create-only (dropbox).  Then _security would become:

  {
    "_readers":{
      "names":["foo","bar"],
      "roles":["baz"]
    },
    "_admins":{
      "names":["jan","brian"],
      "roles":["support"]
    },
    "_replicators":{
      "names":["cron"],
      "roles":["baz"],
    },
    "_creators":{
      "names":["foo"],
      "roles":["_anon"],
    },
    "other_security_stuff":{...}
  }

Now, the top-level keys there are exactly what I called "rights", and would
be enforced in erlang by check_is_admin, check_is_reader,
check_is_replicator etc.

You can keep the data structure exactly like that. All I'm offering is that
you *could* turn the structure on its head like this:

  {
    "names":{
      "foo":["_reader","_creator"],
      "bar":["_reader"],
      "jan":["_admin"],
      "brian":["_admin"],
      "cron":["_replicator"]
    },
    "roles:{
      "baz":["_reader","_replicator"],
      "support":["_admin"],
      "_anon":["_creator"]
    },
    "other_security_stuff":{...}
  }

I prefer this format because all the rights for one user/role are in a
single place; consequently it's easier to remove all access for a user.

The other benefit is that Futon can also display application-specific rights
without being confused by other stuff at the top level of the _security
object; and, if extra couchdb rights are added, Futon doesn't need to
change.

For example, it would be hard for Futon to display the extra 'doctors'
rights from this:

  {
    "_readers":{
      "names":["foo","bar"],
      "roles":["baz"]
    },
    "_admins":{
      "names":["jan","brian"],
      "roles":["support"]
    },
    "doctors":{
      "names":["foo","jim"],
    },
    "hmac_key":"abc12345",
  }

("doctors" having significance in validate_doc_update and _show/_list)
because it wouldn't know which of "doctors" and "hmac_key" should be
displayed as an ACL.  But if you restructure it as

  {
    "names":{
      "foo":["_reader","doctor"],
      "bar":["_reader"],
      "jan":["_admin"],
      "jim":["doctor"],
      "brian":["_admin"],
    },
    "roles:{
      "baz":["_reader"],
      "support":["_admin"]
    },
    "hmac_key":"abc12345"
  }

then futon can show that jim is a doctor, and allow the doctor right to be
added to other users.

The functionality is ultimately the same though, so I'm not wedded to the
second format.

Regards,

Brian.

Mime
View raw message