How to handle users in `_users` database with many applications in the same CouchDB instance?

Question

According to Matt Woodward's Blog, in The Definitive Guide to CouchDB Authentication and Security he points out some things about CouchDB that I'm not sure I understand completly.

1. He says:

   "Basically the way security works in CouchDB is that users are stored in the _users database (or elsewhere if you like; this can be changed in the config file)...".

So, all users of the whole CouchDB are stored in a single database, right? Which means that if I have more than one application running in different databases within the same CouchDB I'd have to handle users who want to access both application, correct?

2. He also says

   "Database readers can only read documents and views on a specific database, and have no other permissions".

   Then, he adds

   "By default all databases are read/write enabled for anonymous users, even if you define database admins on a database".

So anonymous users can or can't read documents in a specific database?

Answer 1

I'll start out by saying that those articles, while still informative, are several years old and possibly outdated. I would recommend reading through the official documentation if you are trying to learn about CouchDB.

Now to answer your question. (more information about security here and here )

In CouchDB, security is something you can incrementally build up as you are developing your application. The default is very open, and you lock things down by adding configuration. (in what I think is a pretty intuitive fashion)

By default, CouchDB is in " Admin Party " mode, which means anyone can read and write anything. (because every user, including anonymous users, are treated as admins)

Once you add any admin users to your server, (via configuration, not the _users database) the party is over. What this means is that some actions can now only be performed by the admin's you've explicitly defined. (such as creating databases, setting config, etc)

In this state, anonymous users can still read/write normal documents in any database that has been created. (design documents can only be modified by admins) If you are ready to start locking down individual databases, you can do that by specifying users/roles in the security object for a given database.

When people use the term "database reader", they mean that a user has been added as a "member" in the security object. (either by their username, or their role) By specifying any members or admins in the security object for a database, then only those users will have permissions inside the database, all others will be disallowed.

To summarize, anonymous users can read/write anything by default. Once an admin is designated, security tightens and certain actions can only be done by that admin. If you specify database members/admins, the security for a database tightens even more, only allowing those users to even read the database.