couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject authentication cleanup
Date Thu, 24 Dec 2009 16:27:25 GMT

I'm attempting to make more sense of CouchDB's authentication system.
The current system is a proverbial ball of spaghetti. I'm still in the
investigation stage of my work, and I'm writing this to clarify my
thoughts and solicit feedback.

To start with, the current default_authentication_handler is unaware
of the users db. I plan to fix that, and to change default.ini so that
cookie_auth is enabled for all Couches. I also plan to make it so that
CouchDB never triggers the basic-auth popup box, because we all know
that that's a UI dealbreaker. (We'll still accept basic auth, we just
won't prompt for it.)

One question is how to manage system roles such as _admin. My thinking
is that the users db validation function will forbid roles starting
with underscore from being stored on user's documents. Instead, when
Couch loads a user from the db, it will cross-reference the user with
the list of node and db admins, and apply the _admin role when
appropriate. This way we can avoid having more than one distinct type
of user in the system. This should also allow us to have more system
roles (prefixed with underscore) in the future.

Another question is bootstrapping the cookie auth system. Currently a
node secret needs to be configured before cookie_auth is enabled. I
don't plan to change that, but I do plan to add a UI workflow to Futon
which encourages you to setup an initial admin user and configure the
secret. Once that is done, cookie auth will be enabled.

At the level of code, I plan to move some things around so most of the
auth stuff is together in the codebase. I'll also be removing the
/_user handler in favor of CouchDB's standard database API + a
validation function. If the /_user handler is widely used, I can
replace it with an _update function which will handle setting up the
hashed password and salt, as well as accepting
application/x-www-form-urlencoded POSTs. If there is concern about
backwards compatibility with existing software, I can also setup an
internal rewrite so that the /_user URL continues to function as it
does now.

I'm also thinking that the /_session handler should speak JSON
primarily (but I'll probably leave in the ability to handle
form-encoded request bodies as well).

As far as security on the users DB, I don't plan to change anything
from how it is now. The basic idea is that anyone can create a new
user document (eg anyone can signup), but only _admins can set roles
on user documents. Additionally, only _admins or the user whos
document it is can update a user document.

In the future, when we implement reader access-control-lists for
databases, they will be useful to further secure the users DB. For
now, the users db will be world-readable, which is fine as long as
no-one breaks the crypto. We're already using strong hashes and long
salts, so I think we're already relatively secure.

None of what I'm doing should change the oauth handlers.

Thanks for your attention. Please fire aware with questions and comments.

Happy holidays,

Chris Anderson

View raw message