Devs, 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 -- Chris Anderson http://jchrisa.net http://couch.io
