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 <[email protected]> wrote: > On Fri, Feb 20, 2009 at 3:48 PM, Stefan Karpinski > <[email protected]> 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 > > <[email protected]> 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 <[email protected]> > wrote: > >>> > >>> On Fri, Feb 20, 2009 at 1:51 PM, Stefan Karpinski > >>> <[email protected]> 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 >
