Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.216.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=G954bq9FJ6AwlqZ+lfchEHt2JxqElpv+HEU9206cyLBBo1SXGRAcqu4HrdVUKx0bZ8
         yderD4fDrosZsQZW6bOH+0g+Jr3iA2KYkK3GkmvZXj/3JcIjgYKnZEWhcbcaozNJP5D/
         wom6rwWHi7QZZGApxY+Bhrxs4hp30MOYLBXnA=
MIME-Version: 1.0
In-Reply-To: <e282921e0912241558w162e054fk94a03a2667f8fe1@mail.gmail.com>
References: <e282921e0912240827t64e37b24l777d6c8f640e972c@mail.gmail.com>
	 <b7cd8ed10912241016w3f946a19qe4f61c32c04e759b@mail.gmail.com>
	 <e282921e0912241558w162e054fk94a03a2667f8fe1@mail.gmail.com>
Date: Sun, 27 Dec 2009 10:47:05 +0100
Message-ID: <b7cd8ed10912270147t586c9e7axcffc0154477ae6b0@mail.gmail.com>
Subject: Re: authentication cleanup
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry was off, hosting family for christmas.

- benoit

On Fri, Dec 25, 2009 at 12:58 AM, Chris Anderson <jchris@apache.org> wrote:
> On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau <bchesneau@gmail.com> w=
rote:
>> On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <jchris@apache.org> wrot=
e:

>
> 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.
>
Basic auth isn't use only by couchapps. Libs need to access to. The
401 response which create the popup is needed by libs too.

>>
>>>
>>> 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 =A0to 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. =A0Keeping 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.
>
The _session by form is already in place and used in some apps. I'm
full for a json api, but also I think that both form and json ap
should be supported as well and since orm api is already in place and
used by apps, it should stay in place and json api just added as
another alternative. One reason for this is that sometimes you don't
want your app speak json but just have an easy way to login. Still
there aren't only couchapps that use couchdb.

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

relatively secure is not enough imo. We should try to make it really
hard to guess a password and more generally to authenticate. Without
that couchdb will never be acceped in some projects.

>>>
>> 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.
>
In any case oauth credentials shouldn't be public. What about if
someone steal the key and use it to log ?


>
> 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.
>
why not choosing the erlang way ? We could associate a node name to
each couchdb node (-sname or -name) which is a dns name. Then all user
ids could be username@nodename ? Which could be an email but not
necessarly. I like the approach used by XMPP and jid for that.

- benoit