Proxy user requests to Couch with common (non-admin) api user

[jkuester]

What feature do you want to improve?

Currently the API server uses several different approaches for authenticated communication with Couch. All users have their sessions authenticated against the _session endpoint to ensure they are a valid user, but then:

• The configured admin COUCH_USER is used for:
  • Doing admin stuff like creating/updating design docs, adding/removing users, etc
  • MITM "attacking" the replication flow of offline users (to control which data they are authorized to access). When an offline user syncs, the api server uses the admin user to actually read/write from Couch.
  • Other various API functions triggered by calls to REST endpoints, etc.
• The actual user logged in on the client is used for:
  • Online users' direct interactions with Couch endpoints are proxied through the API server to Couch with the online user's actual session.

Describe the improvement you'd like

For better simplicity and consistency in these various workflows, I want to propose that the API server be updated to use a new non-admin user for performing all operations except those that explicitly require admin access:

• Admin COUCH_USER:
  • Doing admin stuff like creating/updating design docs, adding/removing users, etc
• Non-admin api user:
  • MITM "attacking" the replication flow of offline users (to control which data they are authorized to access). When an offline user syncs, the api server uses the admin user to actually read/write from Couch.
  • Other various API functions triggered by calls to REST endpoints, etc.
  • Online users' interactions with Couch endpoints are proxied through the API server and to Couch using the api user

With this approach, the _session endpoint would still be used to authenticate the current user, but it would be trivial to enhance this authentication flow to support SSO by authenticating against a 3rd-party IDM service instead.

Describe alternatives you've considered

In the future when we no longer proxy any requests directly to Couch, maybe it would not matter to just have all API interactions with Couch be via the admin user... 🤔 Then the api user would be unnecessary and redundant. On the other hand, maybe it is better for data security/consistency to prefer using a non-admin user either way....

Alternatively, instead of needing to create/maintain a new api user for the api server to use when talking to Couch, we could enable Proxy Authentication on Couch which would allow the api server to interact with Couch via one or more "virtual users" by means of a secret shared between api and Couch. E.g. for each request that the API gets from the client, it would:

• Authenticate the user session by calling _session for the current user
• Hash the user's username with the secret
• Call the necessary Couch resource endpoints with the proxy auth headers set (including preset role(s) for the api server that are not specific to the current user). The idea is that all authorization happens in the API server and the user's roles are not relevant for the Couch interactions....

These approach seems really nice since we don't have to maintain an additional user and we could also have additional traceability for each request since "username" for each proxy auth request sent to Couch could actually match the actual end user (instead of having all Couch traffic be just from the generic api user).

Additional context

Not sure how relevant this actually is, but seems worth noting that I think we are moving away from using session cookies on the server side?!? #8338

[jkuester]

Another potentially interesting possibility unlocked by the proxy auth approach here would be that I think it would mean we that if we inject the COUCH_SECRET into the api server, we would not need to inject the COUCH_USER and COUCH_PASSWORD. In the proxy auth scenario, the difference between an "admin" request and a "non-admin" request could just be whether or not the API server includes the _admin role in the proxy auth header or not....

Not sure if this actually gives us any meaningful benefits, though....