I'm not entirely clear what level of user auth is being addressed here.
On the one hand, there's the system-level sense of a user that traditional
databases have: i.e. something equivalent to a UNIX user account, but in the
database, which has to be created by an admin and can then be granted
table-level access and various administrative rights (create user, create
database, create table).
On the other hand, there's the application-level sense of user: i.e. a
record in a users table, which is given access or not given access to
database records via the web application stack at a higher level, which sits
between the database and the client's web browser (or whatever).
The current CouchDB notion of admin user seems to fall into the former
category, while what most applications need falls into the latter category.
One irritation of all application-level authentication schemes I've ever
encountered is that the database does not give you any support for
application-level user auth. If CouchApps are really going to be feasible,
CouchDB (clearly) needs to solve the application-level user authentication
problem.
My sense is that the goal is to somehow merge the two senses of database
user, and thereby cleave the Gordian knot in two. Is that sense correct?
On Fri, Feb 20, 2009 at 1:24 PM, Chris Anderson <jch...@apache.org> wrote:
> d...@couchdb,
>
> There's been much talk about how to store user accounts in CouchDB
> databases . There are a few questions about the model, and description
> of how the default handler works.
>
> Currently Admin accounts are specified under config on a per node
> basis. See couchdb_httpd:default_authentication_handler/1 for the
> implementation. By making your own alternate auth handlers, you can
> setup user_ctx for validation functions.
>
> To override couchdb_httpd:default_authentication_handler in your local
> install, edit your local.ini and add a line like:
>
> authentication_handler = {couch_httpd, my_authentication_handler}
>
> to the [httpd] section.
>
> Now you're ready to start hacking!
>
> I'd encourage you to reuse basic_username_pw(Req), and
> couch_server:is_admin(User, Pass) in your implementations. Once you've
> database-lookup for usernames happening, you'll have to make a
> decision about how to handle the case where the same username and
> password combo works for both user and admin accounts.
>
> Ideally you'd want to prevent collisions between admin and user
> accounts. But you can't very well prevent writes to the local.ini
> file, so... maybe they need different login endpoints. I'm not sure
> what to do here, this is a sticky bit.
>
> I'm interested in loading user creds from an "accounts" database
> (specified on a per-node basis, for simplicities sake). To handle
> encryption, we'll have to have a node-secret, which can probably be
> uniquely generated by Couch on boot if it doesn't exist (of course,
> over-rideable in local.ini)
>
> Jason Davies has been working on a /_login screen, and an untamperable
> cookie store, so that creds don't have to be loaded on each request.
> Client-state ftw!
>
> Untamperable cookies can be subject to session stealing attacks, so
> they'll need to be run under SSL if security is important.
>
> There's still the database-admin role to account for, so let's not
> forget there are details unaccounted for here.
>
> Hoping to kick off the conversation.
>
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
