couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: authentication cleanup
Date Thu, 24 Dec 2009 18:16:26 GMT
On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <jchris@apache.org> 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

Mime
View raw message