On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <[email protected]> wrote: > 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.)
Auth popup is created by the browser. Does it imply an ui would be needed to connect to CouchDB via the browser ? Also how can we detect the basic auth if you don't send the 401 status with WWW-Authenticate ? I think we should keep the default behaviour (popup) but on the other hand reusing the system used with cookie aut allowing us to not popup by just providing another header. > > 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. Not sure to follow here.Do you plan to remove admins from ini ? I would be to keep them. They are like super users. We could create another class of users for that. Maybe _staff to follow unix terminology? > > 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. +1 > > 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 guess the _user rewrite could go with the rewriter i will show this we. (pure erlang) > > 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). > We could just detect http headers and provide the needed response for that. Keeping the form encoded would be good. It's already used in some applications. > 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. > Not really since salt is available and hash is only sha1. I think we could make it harder but I agree with a strong encryption we don't need to hide them. > None of what I'm doing should change the oauth handlers. oauth is a problem here if it's in a public db. > > Thanks for your attention. Please fire aware with questions and comments. > > Happy holidays, > Chris > Thanks you too. I would be happy to help on this part I have a project that just wait for a some auth. So tell me if I can help. - benoît
