couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Karpinski <stefan.karpin...@gmail.com>
Subject Re: User Auth
Date Sat, 21 Feb 2009 06:41:17 GMT
Ok, good to know. I could go did around the development code, but it might
be much more expedient just to ask. Is there a special users database? What
about sessions? It would be cool if those were just databases with special
metadata (only settable by admin users, of course). What's in a user_ctx
object at the moment? Does it correspond to an actual CouchDB record?

On Fri, Feb 20, 2009 at 3:56 PM, Chris Anderson <jchris@apache.org> wrote:

> On Fri, Feb 20, 2009 at 3:48 PM, Stefan Karpinski
> <stefan.karpinski@gmail.com> wrote:
> > Thoughts (just brainstorming here):
> >
> > I think it makes sense to separate authentication and permissions.
> > Pure authentication is just about verifying that the user is who they
> > claim to be. Permissions are about deciding which users are allowed to
> > see or do what. Cleanly separating is good: ideally you should be able
> > to completely swap out your authentication mechanism, switching from,
> > say basic auth to SSL + digest auth, and keep the application logic
> > about who gets access to what completely unchanged. For example,
> > Apache accomplishes this by doing whatever authentication it's doing
> > and then passing the REMOTE_USER environment variable
> > (http://httpd.apache.org/docs/1.3/misc/FAQ-F.html#remote-user-var)
> > with the authenticated user name. Whatever CGI or variant thereof
> > (FCGI, etc.) then just does whatever it sees fit to do with that user
> > name.
> >
> > Also, authentication is typically slow: even hashing a user/pass combo
> > takes some CPU — this is not something that you want to have done on
> > every request. That's why the notion of user sessions exists (at least
> > from the security perspective; there are other notions of session).
> > That argues for having the CouchDB server process manage
> > authentication and letting the application developer define custom
> > functions for deciding whether (user,resource) pairs are acceptable or
> > not. I.e. the CouchDB process somehow validates that the request is
> > coming from someone who has provided adequate proof that they are who
> > they claim to be, via HTTP basic/digest auth or whatever. Then the
> > application can just decide whether the pre-authenticated user is
> > allowed to access a particular resource.
> >
>
> This is pretty much how it works now. CouchDB manages sending the
> user_ctx object into the validation function. The user_ctx object then
> lets the function know if the user is an admin or in any other groups.
> Then the validation function may accept or reject the update
> accordingly.
>
> There is a related issue about how to let the client application know
> which user they are validated as, so that they can correctly fill out
> author fields etc.
>
> > More thoughts coming...
> >
> > On Fri, Feb 20, 2009 at 3:16 PM, Stefan Karpinski
> > <stefan.karpinski@gmail.com> wrote:
> >>> I wish I could say we've got such a clear picture of it.
> >>
> >> Good to get in on the planning stages!
> >>
> >>> The easiest way to cleave the knot is probably to rely on 3rd party
> >>> auth like OpenID or OAuth (I don't quite know which parts of which
> >>> we're interested in).
> >>
> >> OpenID is great, but I don't think it's viable to force people to use
> it.
> >>
> >>> Identifying users as URLs would make things easier on application devs,
> I think.
> >>>
> >>> If every app will need to implement something like this, it makes
> >>> sense to me to have the CouchDB host manage the session, even if apps
> >>> can keep their own user-preferences docs if they wish. Being logged
> >>> into all the apps on a node seems a lot more intuitive than having to
> >>> create accounts for each one. If the user is identified with a URL,
> >>> then preferences etc can be replicated to other hosts while everything
> >>> "just works".
> >>
> >> I think that nailing this problem would go a *long* way towards making
> >> CouchDB popular not only for it's nice distributed properties and
> >> such, but also because would make writing modern web apps drastically
> >> easier. Because literally *every* non-trivial web application needs to
> >> do user authentication. Having it _just work_ without having to worry
> >> about it is a massive win. Moreover, if the database was actually
> >> aware of application-level authentication and could enforce it, then
> >> it would increase the security of CouchDB-based web apps. Errors in
> >> business logic would be much less likely to accidentally expose data.
> >> How easy is it to forget in Rails that you need to filter the objects
> >> in some table by the user_id field?
> >>
> >> On Fri, Feb 20, 2009 at 3:01 PM, Chris Anderson <jchris@apache.org>
> wrote:
> >>>
> >>> On Fri, Feb 20, 2009 at 1:51 PM, Stefan Karpinski
> >>> <stefan.karpinski@gmail.com> wrote:
> >>> > 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?
> >>>
> >>> I wish I could say we've got such a clear picture of it.
> >>>
> >>> The easiest way to cleave the knot is probably to rely on 3rd party
> >>> auth like OpenID or OAuth (I don't quite know which parts of which
> >>> we're interested in).
> >>>
> >>> Identifying users as URLs would make things easier on application devs,
> I think.
> >>>
> >>> If every app will need to implement something like this, it makes
> >>> sense to me to have the CouchDB host manage the session, even if apps
> >>> can keep their own user-preferences docs if they wish. Being logged
> >>> into all the apps on a node seems a lot more intuitive than having to
> >>> create accounts for each one. If the user is identified with a URL,
> >>> then preferences etc can be replicated to other hosts while everything
> >>> "just works".
> >>>
> >>> Thanks for the feedback!
> >>>
> >>> --
> >>> Chris Anderson
> >>> http://jchris.mfdz.com
> >>
> >
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message