couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: authentication cleanup
Date Thu, 24 Dec 2009 23:58:55 GMT
On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> 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.

I think it is possible to accept basic-auth when users provide it,
without sending the sort of response that triggers the popup in the
browser. If you have to have that popup to be RESTful, then I don't
want to be RESTful. On a serious note, I can't imagine anyone ever
writing a serious CouchApp if the browser-auth-popup is lurking there,
ready to ruin the user experience at every turn.

>
>>
>> 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?
>

I don't plan to remove admins from the config. The _admin role will be
applied to users in the users db, based on the config setting. (Also,
if you don't use the user's db, you will not notice any change at
all.)

Another _role that we could add in the future is a _replicate role,
which normal users could have the option to run replication under.
This would allow validations to enforce things like author names,
without requiring users to run replication as _admin and expose design
docs to potential unwanted changes.

>
>>
>> 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.

I think we'll end up supporting both, but I want to get the JSON API
in place and well tested.

>
>> 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.
>

I agree hiding the users db would be more secure, but the current
codebase uses a public users db. I've got to draw the line for this
patch somewhere. Should we eventually get per-db reader ACLs, they'll
be perfect for making this a little more secure.

>
>>
>> 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
>

The code I've written so far is a huge mess, so there's not much room
to help at the moment. I'll hopefully have it in a publishable state
in the next few days. (yay to holidays, the one time I can actually
get work done!)

One problem I've run into is how to enforce that logins are unique
within the users db. The simple answer is to make the username into
the docid. This has the upside that if 2 sites are replicated
together, any duplicated user docs will go into a conflict state
immediately. I think this is better than having the ambiguity come up
at login time, when it's not clear which user document to test the
password against.

If we do login-as-docid, then we can encourage people to use email
addresses as login tokens, which should help avoid spurious conflicts
when sites are merged.

The other option is to keep doing what we do now, and run a view query
to see if the user name has been taken before saving the document.
This has the advantage of mostly working while avoiding replication
conflicts. However, as I said above, I think we want those replication
conflicts. Also, having a uniqueness constraint on a field other than
_id is one of those things that seems like it works, until it doesn't
work. Then when it doesn't work (b/c of distributed apps or race
conditions) the whole house of cards comes falling down.

So I think I'm gonna switch to docids like "user:jchris@apache.org"
and "user:Monty4eva". If this is a stupid idea please convince me not
to do it.

Cheers,
Chris

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

Mime
View raw message