feat: add couch configs to enable proxy authentication

[rmayore]

Description

• Simple couchdb configuration update to enable proxy authentication

Building couchdb image with proxy auth enabled

1. Clone this fork, and pull from this branch
2. npm ci
3. npm run build-dev
4. Build images locally with the command npm run local-images
5. docker image ls to get the new, timestamped, locally build couchdb image
6. Start your couchdb container using the new image. If you're running your couch using the docker compose template, replace the image name with the local one in the docker-compose.yml file

Restarting existing couchdb container with proxy auth enabled (thanks @mrjones-plip)

1. get to the couchdb shell with docker exec -it cht-docker-couchdb-1 bash
2. edit the config in vi /opt/couchdb/etc/default.d/10-docker-default.ini. You might have to install your favorite editor if it's not present in the container
3. Have your config changes take effect by restarting. do this by exiting the container shell and running COUCHDB_USER=medic COUCHDB_PASSWORD=password docker compose -f docker-compose.yml -f couchdb-override.yml restart

Generating proxy auth token

Use the secret to generate a HMAC of the username... this will become our proxy token.
echo -n "username" | openssl dgst -sha256 -hmac "the_secret"

Code review checklist

• UI/UX backwards compatible: Test it works for the new design (enabled by default). And test it works in the old design, enable can_view_old_navigation permission to see the old design.
• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[jkuester]

@rmayore this is great! I pulled down the changes and was able to get everything running locally. Thank you for the detailed instructions!

I just left some minor comments inline. 👍

One question I am interested in getting everyones' thoughts on is if we think it would be a problem to have the proxy_authentication_handler always enabled (even when a deployment is not using SSO)? It seems like you can enable it without any disruption to the default/cookie_authentication_handlers, so probably the only concern would be around security. The proxy auth could theoretically increase the attack surface since it allows admin access to anyone with the secret and direct access to the Couch instance. However, I am not sure this is a major concern. The Couch secret is already carefully managed with the other sensitive values such as the admin user/pass. Additionally, on a proper production deployment, the Couch ports should not be accessible. Instead all traffic should be proxyed through the api server. Thoughts?

[jkuester]

I don't think we need to set this here. It is already set on line 20 (and I think it belongs in the chttpd section antyway).

Suggested change

require_valid_user = true

[jkuester]

I also do not think we need to hard-code the secret here. Unless I am mistaken, the COUCHDB_SECRET envar you can supply to the couch container gets set as the httpd_auth.secret value.

Suggested change

secret = 5ec56423-0856-4b13-8ab7-9b476fea2c39 ; CHANGE ME - proxy secret

[jkuester]

It looks like you just kept the default values for these header names. As far as I know, the default values should work fine for our case, but do we even need to include this config here if we just use the default values?