gramsa49 opened a new issue #1057: shared secrete for proxy authentication
URL: https://github.com/apache/couchdb-fauxton/issues/1057
 
 
   CouchDB should be extended to allow for the use of a shared secret to 
authenticate external proxies that provide authentication services to end users 
of couchdb.
   
   This differs from the existing secret/token based validation in the 
following ways:
   * Does not require a sha1-hmac of the shared secret and the username
   
   Instead, the shared secret is a static value used to authenticate the proxy 
and not the users passing through the proxy.
   
   The shared secret would be configrued in both CouchDB and the proxy.  The 
secret would be passed to CouchDB by the proxy in an HTTP request header.
   
   ## Expected Behavior
   The current secret/token configuration is not compatible with external 
systems such as httpd, nginx, haproxy, and the likes because the token must be 
generated for each user.  Take the following example for user1 and user2:
   
   Assumed Configuration Parameters for CouchDB:
   
   [chttpd]
   authentication_handlers = {couch_httpd_auth, proxy_authentication_handler}, 
{chttpd_auth, default_authentication_handler}
   require_valid_user = true
   
   [couch_httpd_auth]
   proxy_use_secret = true
   secret = s3cr3t
   require_valid_user = true
   x_auth_roles = X-Auth-CouchDB-Roles
   x_auth_token = X-Auth-CouchDB-Token
   x_auth_username = X-Auth-CouchDB-UserName
   
   The following headers must be passed for user1:
   X-Auth-CouchDB-Roles: role1
   X-Auth-CouchDB-Token: 5350d04e1e71b5651ac44339e211c17faece36ce
   X-Auth-CouchDB-UserName: user1
   
   The following headers must be passed for user2:
   X-Auth-CouchDB-Roles: role1
   X-Auth-CouchDB-Token: b54fe2ef8cd5e013eea692063f99365b1e1773b9
   X-Auth-CouchDB-UserName: user1
   
   I don't see a good way to accomplish this with Apache httpd.  In the 
proposed enhancement, the following HTTP headers would instead be passed:
   
   for user1:
   X-Auth-CouchDB-Roles: role1
   X-Auth-CouchDB-Secret: s3cr3t
   X-Auth-CouchDB-UserName: user1
   
   for user2:
   X-Auth-CouchDB-Roles: role1
   X-Auth-CouchDB-Secret: s3cr3t
   X-Auth-CouchDB-UserName: user1
   
   ## Current Behavior
   The current secret/token configuration is not compatible with external 
systems such as httpd, nginx, haproxy, and the likes because the token must be 
generated for each user.  
   
   ## Possible Solution
   Add a new configuration parameter, x_auth_secret.  Map this to a new HTTP 
request parameter.  Use this to validate the secret passed by the proxy against 
the secret used by couchdb.
   
   ## Steps to Reproduce (for bugs)
   Attempt to configure a proxy using apache httpd for certificate based 
authentication and use the existing secret/token to authenticate the proxy.  I 
don't see a good way to do this.
   
   ## Context
   This is a common implementation pattern for software that integrates with 
external authentication systems.  My specific use case is as follows:
   * Users authenticate to Apache httpd using a client certificate
   * Apache httpd validates the Issuer of the client certificate
   * Apache httpd extracts the CN from the client certificate
   * Apache httpd sets http header 'X-Auth-CouchDB-UserName' to the CN from the 
client certificate
   * Apache httpd proxies the http request to couchdb
   
   Without the ability to authenticate the proxy in couchdb, anyone with 
terminal access can impersonate any user at will, including the admin user.
   
   ## Your Environment
   * Version used: Couchdb 2.1.1
   * Browser Name and version: curl 7.52.1
   * Operating System and version (desktop or mobile): debian 9.3
   * Link to your project: n/a
   * Proxy: apache httpd 2.4.25
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to