Redesign CouchDB security system

[wohali]

@janl:

• closed by default
• more fine-grained permissions
• more options for delegated authentication

Our security system is slowly grown and not coherently designed. We should start over. I have many ideas and opinions, but they are out of scope for this. I think everybody here agrees that we can do better. This very likely will not include per-document ACLs as per the often stated issues with that approach in our data model.

@davisp:

Big +1 on this. The auth stuff in our code base is hard to follow and difficult to hold in my brain. Taking a step back to redesign from the ground up would be super awesome.

[mikerhodes]

It would be good to see a clearly defined security layer cut through the database horizontally in any refactoring / building from scratch (e.g., sitting above fabric, so anything below fabric can assume authorised). This would also help a lot with any efforts to separate out different database subsystems, if, e.g., the whole storage subsystem doesn't have to care about users, roles etc.

[wohali]

Some links:

@rnewson today mentioned implementing XACML at IBM/Cloudant to replace the current roles system, and I don't see any reason we couldn't consider mirroring this framework, if not the implementation. (Eew, XML.) Robert is going to ask @kocolosk how much of the IBM implementation he can discuss in public. In short, their model doesn't have the PDP layer inside of Couch; if we took the same approach, we'd have to build a PDP inside of Couch, which could consult whatever source of information it wanted. This might or might not include such things as _security objects, depending on how we wish to implement things.

The thought occurred to me that web-of-trust systems might be useful in this space as well, since it was mentioned on the Wikipedia page for XACML. It'd be especially interesting from a CouchDB replication trust model as well. I think this might be a separate ticket, however. Upcoming (but not yet widespread) standards in this space include DID and OCAP-LD from the W3C.

[mikerhodes]

Mostly, for me, there are a few things that our IAM implementation does which would be really nice:

• Convert a request (based on request path) to a symbolic action name which can then be used for authz and for request dispatching within the system (rather than having various places parsing URL paths etc.). E.g., couchdb.db.read-document.
• There is a flexible actions to roles mapping that can be set up by an admin -- so we'd be able to allow a couch admin to create and "operator" role and specify what that role has access to (e.g., the various _info endpoints, things under /_admin and so on).
• Likely the _security doc format needs to be altered to allow for a more flexible role/user/group mappings.

I like the idea of chttpd converting the HTTP request into some kind of object that's specific to the request being made, like a view request, and validating all the parameters when creating that request-specific object, rather than passing down the HTTP request itself. I think this would be needed to really have a solid security split, as the lower levels could assume both the request is allowed and that the data can be trusted.