couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Auth Roadmap
Date Wed, 10 Feb 2010 15:26:00 GMT
On Wed, Feb 10, 2010 at 2:12 AM, Brian Candler <B.Candler@pobox.com> wrote:
> On Wed, Feb 10, 2010 at 12:24:26AM +0100, Benoit Chesneau wrote:
>> I've read all the thread, and I'm not conviced all readers and admins
>> should be in one doc. List could be long also it would require to
>> check if one already exists some stuff like it. Why not putting all in
>> their docs and making a view on it ?
>
> I'd prefer a real doc or docs too.
>
> But if we have to have an opaque non-scalable non-document object, it would
> be better to have one of these things rather than three of them.
>
>> > 3) More system roles.
>> >
>> > Brian also mentioned something about _user and _anon roles which could
>> > be applied to the userCtx automatically. This would be handy in both
>> > per-db access control and in validation functions. This will be a bit
>> > harder to implement as it touches more of the codebase. I'm also
>> > uneasy about these roles as they raise the burden for implementors of
>> > pluggable authentication modules.
>>
>> Everyone could be _anon instead of _admin though.
>
> Maybe _anon isn't even needed, because they will have "name":null.
>
> But you'd want a way of saying "any logged-in user", which could be as
> simple as adding a fixed role like "_user" to everyone who has a non-null
> name. And if you're going to do that, you might as well add "_anon" role to
> everyone who has a null name. Sounds easy to me, but I've not tried coding
> it yet.
>
>> > We should also think about making it possible for
>> > _admins to interact with the database without the _admin role. They
>> > could trigger admin actions with something like sudo.
>
> That's where having a real document would win, because you could use
> validate_doc_update for this logic.  Such logic already exists in the _users
> database, to prevent non-admins from adding roles to themselves.
>
> Personally I think that if a system admin is a role, then a database admin
> should be a role, and a database reader should be a role (and by extension,
> you could have a system reader role)
>
> Suppose the per-database _security doc or object looked like this:
>
>  {
>    "names":{
>      "brian":["_admin"],      # brian is database-level admin
>      "jan":["_reader"],
>      "bob":["_reader","foo"]  # foo role has local significance
>    }
>    "roles":{
>      "support":["_reader"]    # anyone with support role can read this DB
>    }
>  }

The problem with this approach, imho, is that currently users have the
same set of roles in every db. That is, your userCtx doesn't change
depending on the db you are accessing. I can see how adding that
capability increases flexibility. But it's the sort of flexibility
that I see having a nasty complexity tax. Eg: currently the /_session
resource is server-wide. As soon as some roles are available on
certain dbs and not others, we need to make it /db/_session which is
misleading as you don't actually log into dbs, you log into the
server. The consequences of per-db roles being applied to users would
ripple through the system as complexity in all sorts of places.

The thing you've got above I'd do as:

jan and bob both have "foobar" in their list of roles in their
documents in the _users db.

the security object looks like:

{
readers: {
names : [],
roles : ["foobar", "support"],
}
admins : {
names : ["brian"]
roles : []
}
whatever else...
}

I think we don't want this object to replicate, as moving data around
shouldn't have a chance of affecting ACLs on the target db.

This is why it is not a document. (It could be a _local document and
have similar semantics, but O(log n) read cost instead of O(1) read
cost. This is why we use a special member.)


>
> You'd merge the roles from the userCtx with these roles to get the effective
> set of roles for this user when accessing this particular database.
>
>> Just to be sure everything is one user db ? Just want to make sure
>> it's possible to replicate all authentification for a node or even a
>> cluster.
>
> That's another reason for doing this in docs. Either make _security a real
> doc within each database, which can replicate along with it; or put the
> authorizations into the _users database (which is easy with
> database-specific roles).
>
> The only objection I've heard to the latter idea is that if a database is
> filesystem-copied or renamed, the authorizations won't move with it.
> Authorizing against a database uuid rather than database name would solve
> that.
>
> Also: given that "bob" on db1 could be a different person than "bob" on db2,
> it seems dangerous to replicate or copy the authorizations from one database
> to another independently of the users database.
>
>> > 5) drop box
>> >
>> > If we had the concept of DBs that you could write to but not read
>> > from, it would make read-controlled _users dbs compatible with new
>> > user signups. This would be not that fun to implement, but potentially
>> > useful for lots of other things too.
>> >
>>
>> +1 on this.
>
> Interesting idea - also for logging databases, audit databases etc. Need to
> think about the semantics.
>
> Possibly POST to the database itself could have its own role, and it would
> ignore _rev so it could only be used to create new docs.  But still some
> other mechanism would be required for users to change their own passwords.
>
> One idea is to split _reader into two; one role would permit access to
> _show, _list and _update whilst blocking all direct access.
>
> Regards,
>
> Brian.
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message