couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Initial couchdb accounts feedback
Date Mon, 11 Jan 2010 21:07:43 GMT
On Sat, Jan 09, 2010 at 07:09:08PM -0800, Chris Anderson wrote:
> > I had a bit of a think about this overnight (since I'll be running in
> > this scenario). If there are dbs that shouldn't share users, perhaps
> > you could prefix the role with the appname. ie: { roles:
> > ["myapp1:editor"] }. Then once there are reader ACLs, you could test
> > that the user included roles with the appropriate prefix.

Having thought a bit more about that, it would work for me too, as long as
the app itself knew that it was called 'myapp1', or else the myapp1: prefix
were stripped from the role before being handed to the application.

Furthermore, if this were made a standard way of mapping app-specific roles,
then you could bundle a well-tested _users/_design/_auth function which
implements the myapp1:admin role.  It's a little hairy so worth doing right.

By the way, once db read access is controlled, is it planned that _all_dbs
should show only the databases to which the user has access? That would be
extremely useful.

> Currently the validation function takes 3 arguments (newDoc, diskDoc, userCtx)
> 
> The plan is to add a 4th argument, which is a security object. It
> would be per-app, and could allow a site (I'm thinking an office or
> some other organization) to map from site-roles to app-roles. So in
> the case of a hospital, you'd set up a mapping between various site
> roles like R.N., M.D., orderly, etc, and application roles
> (prescription-writer, prescription-filler, etc in the prescription
> app.)

Perhaps what you've written could be more clearly expressed as
   users -> groups; groups -> app roles.

I wouldn't need that myself, but I can see how it would be useful in
situations where all the apps on a server are in the same administrative
domain. All I need is users -> app roles (which could be implemented in
tandem with the above, of course)

If there are going to be groups, then you need more documents. The obvious
solution would be a group doc as well as a user doc:

    "type":"user",
    "username":"fred@example.com",
    "groups":["rn","orderly"],          # user -> group(s)
    "roles":["prescriptions:admin"],    # user -> app role(s)

    "type":"group",
    "groupname":"rn",
    "roles":["prescriptions":"create"]  # group -> app role(s)

But could you also consider one document per *application*:

    "type":"user",
    "username":"fred@example.com",
    "groups":["rn","orderly"]

    "type":"authz",
    "db":"prescriptions",        # the name of the database
    "users:{
       "fred@example.com": ["admin"],
    },
    "groups":{
       "rn": ["create"],
    }

Then when you clone/replicate/delete a database, there is only one authz doc
which needs to be copied/deleted too.  This is exactly what my app does at
the moment, but in middleware.

Does that "authz" document represent what you are calling a "security
object"?

Regards,

Brian.

Mime
View raw message