Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 208.72.237.25 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to
	:subject:message-id:mime-version:content-type:in-reply-to; q=
	dns; s=sasl; b=AopqJosHTmyKLsBjiUuFnYF3V379VpNfri+TSuO9HnQ6ZbEqx
	NK1JMYSM7P1DYnpRH+lI5tb20EV72EzcnM025ek4mXIuVuhkQfVqWAXJALfvbqJD
	jo0RQB7nYxgc2z8kPrbtL9Rr94qtwzm+2EZIeCjmYg9TBr2XMR/veUZhj0=
Date: Sun, 10 Jan 2010 19:05:59 +0000
From: Brian Candler <B.Candler@pobox.com>
To: user@couchdb.apache.org
Subject: Re: Initial couchdb accounts feedback
Message-ID: <20100110190559.GA8839@uk.tiscali.com>
Mail-Followup-To: user@couchdb.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e282921e1001092256h939a8abhaf3b124192b0bb08@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

> I'm not sure about adding this complexity. What if the user is
> experiencing a network partition from their email provider? They
> should still be able to sign up.

It seems the answer will be different for different people.

For me, the answer is that they absolutely should *not* be able to sign up
as this particular user, without being able to prove it is them. And this
goes to a matter of trust: if I add a role "doctor" to user
"fred@example.com", I need to be sure that "fred@example.com" really is the
person with that E-mail address, and not some imposter who happened to
choose that username just because they got to the server first.

I imagine the same will be true for any public hosting which sells space
for individual dbs on a shared couchdb instance.

But others have said they're quite happy to have first-come-first-served
non-validated usernames. So this is a matter of policy, and it needs to be
pluggable.

> I would *love* to see an easy email loop that CouchApps can access.
> 
> I bet the Raindrop project has exactly the code you'd need to
> implement this as a CouchApp + external.

But if you implement it as a couchapp, don't you have to trust the client? 
CouchApps are just regular clients, so if clients can insert random stuff
into the user[s] db, then you can't know that it's been properly validated. 
Hmm, or maybe the validate_doc_update can check for a signed cookie or
something like that (as long as you are very careful that the design doc for
the user[s] database is not readable!!)

What about my other point, that roles should be per database, not global?

Let me put it another way. I have an application here, currently written in
Rails, which has a separate couchdb database per customer.  It has a simple
rights model: the owner of a particular database can permit other users to
access it (either read-only, update, or owner level privileges).  When a
user logs in, they get to choose which of the database they have access to
that they'd like to work with.

It's starting to look like I could rip out a whole load of the application
concerned with signup, session and authorization handling - even turn the
whole thing into a couchapp, moving all the user interface into the client. 
But for me to be able to do this, the following would have to be possible:

(1) Usernames have to be securely linked to the individual. OpenID would be
fine, but that's too complicated for most people, so I'm using E-mail
address with activation link.  Otherwise, granting permissions to "bob"
could be granting it to anyone.

(2) Roles have to be per database. For example, "bob@example.com" might be
the owner of db1, have read access to db2, and no access at all to db3.

I could of course frig the roles to include the db instance name, e.g.
   "roles": ["db1:owner", "db2:read"]
but:

(3) The 'owner' of a database needs to be able to grant access to other
users. So bob@example.com, who has role db1:owner, needs to be able to grant
or remove db1:<any> from any user on the system.

It would be fine if the roles were stored as document(s) within db1, because
I could use validate_doc_update to allow anyone with the appropriate role to
update them.

As couchdb is now, where the roles are stored within the global user[s]
database, they can only be managed by a couchdb server administrator. So
this would mean I'd have to have a middleware program running with server
admin privileges by which user X could request a grant/revoke of role R to
user Y on database Z. And what's tricky is that the user X would have to be
able to prove their identity to that middleware app when sending the
request.

Right now, I can't move the authentication and even this coarse level of
authorization into couchdb, and therefore I can't expose couchdb to the
world without the middleware layer.

Note that I'll still need a small trusted middleware program running as
couchdb server admin, which would be used for creating new databases (and
perhaps also billing them), and deleting ones which are no longer required.

Regards,

Brian.