couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Auth Roadmap
Date Tue, 09 Feb 2010 22:52:28 GMT
Devs,

I've been getting a lot of feedback about the authentication &
authorization work that I did over the holidays and over the last few
weeks. There are also some enhancements I've been thinking about for a
while. Here's a quick list of what I see as the important things to
do. I'm not concerned here with releases / feature freeze etc as in my
opinion CouchDB development is expected to continue even after we
reach 1.0.

1) Extensible password storage.

Thanks Brian Candler for the links to the OpenLDAP style of storage. I
think we should do this asap so we don't have to worry about backwards
compatibility with the current storage mechanism until the end of
time. The relevant message:
http://permalink.gmane.org/gmane.comp.db.couchdb.devel/7588

2) ACLs / Security Object

I couldn't originally think of a reason the validation funs would need
to see the per-db admins / readers lists. Brian has a use case for
this. Also, I think I can accomplish this feature while also
simplifying the implementation. I'd like to make it so each db has an
/_security object that contains admins and readers (in their current
form, but as fields on the object, not as separate object at different
URLs). This entire object would be made available to the validation
functions.

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.

Going forward we maybe want to add a _replicator role (or maybe that's
a horrible idea). 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. I want to put
this off for now, because it's complicated and worse-case scenario is
people don't realize they need to "sudo" to get things done, and come
away thinking CouchDB is fighting with them.

4) _temp_views and _all_dbs (maybe more)

Regardless of whether the above is done, for 1.0 we should clean up
any bugs like these.

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.


I hope this clears things up for people. The only other thing I feel
compelled to add is that CouchDB has never had (and probably never
will have) any concept of per-document read control. It is too fraught
with pitfalls, and even the best ideas about how to enforce
per-document read-control put an unacceptable burden on implementors
of alternate view engines.

Again, this is open-source, so scratch your own itch, feel free to
write patches, argue about all this, etc.

That said, if nothing but #4 ever gets done I'd still be proud of the
system as it stands today, as I think it's more or less the simplest
thing that could possibly work.

Cheers,
Chris

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

Mime
View raw message