1. Sebastian Sebastian
  2. scm-manager
  3. Issues

Issues

Issue #408 resolved

Other authentication fliters aren't used for checkout when behind a reverse proxy

Anonymous created an issue

We have scm-manager running behind an Apache reverse proxy with SSL. We also have scm-crowd-plugin installed to allow Crowd users to authenticate. This works as expected for browsing scm-manager's web interface, and even browsing the underlying hgweb for our Mercurial repository. However, when we try to clone our Mercurial repository from the command line (as a Crowd user), authentication fails. However, when bypassing the reverse proxy, cloning works.

This is what we get from the Mercurial command:

$ hg --debug --verbose clone https://<HOSTNAME>/scm/hg/<REPO>
using https://<HOSTNAME>/scm/hg/<REPO>
sending capabilities command
<HOSTNAME> certificate successfully verified
http authorization required
realm: SONIA :: SCM Manager
user: <CROWD_USER>
password:
http auth: user <CROWD_USER>, password **************
<HOSTNAME> certificate successfully verified
http auth: user <CROWD_USER>, password **************
<HOSTNAME> certificate successfully verified
http auth: user <CROWD_USER>, password **************
<HOSTNAME> certificate successfully verified
http auth: user <CROWD_USER>, password **************
<HOSTNAME> certificate successfully verified
http auth: user <CROWD_USER>, password **************
<HOSTNAME> certificate successfully verified
http auth: user <CROWD_USER>, password **************
<HOSTNAME> certificate successfully verified
abort: authorization failed
$

This is what the server logs show (with trace logs):

19:42:27.742 [qtp2075530176-29] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized
19:42:28.069 [qtp2075530176-20] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized
19:42:28.399 [qtp2075530176-29] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized
19:42:29.182 [qtp2075530176-20] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized
19:42:29.509 [qtp2075530176-29] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized
19:42:29.821 [qtp2075530176-20] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized

This is what the server logs show for plain HTTP (when Crowd authentication works without ):

19:43:30.126 [qtp2075530176-84] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - could not find user send unauthorized
19:43:37.010 [qtp2075530176-84] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - found basic authorization header, start authentication
19:43:37.011 [qtp2075530176-84] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - try to authenticate user <CROWD_USER>
19:43:37.012 [qtp2075530176-84] TRACE sonia.scm.web.security.ChainAuthenticatonManager - no authentication result for user <CROWD_USER> found in cache
19:43:37.012 [qtp2075530176-84] TRACE sonia.scm.web.security.ChainAuthenticatonManager - start authentication chain for user <CROWD_USER>
19:43:37.033 [qtp2075530176-84] TRACE sonia.scm.web.security.ChainAuthenticatonManager - check authenticator class sonia.scm.web.security.DefaultAuthenticationHandler for user <CROWD_USER>
19:43:37.033 [qtp2075530176-84] DEBUG sonia.scm.web.security.DefaultAuthenticationHandler - <CROWD_USER> is not an xml user
19:43:37.034 [qtp2075530176-84] DEBUG sonia.scm.web.security.ChainAuthenticatonManager - authenticator sonia.scm.web.security.DefaultAuthenticationHandler ends with result, user: null, state: NOT_FOUND
19:43:37.035 [qtp2075530176-84] TRACE sonia.scm.web.security.ChainAuthenticatonManager - check authenticator class sonia.scm.crowd.CrowdAuthenticationHandler for user <CROWD_USER>
19:43:37.035 [qtp2075530176-84] DEBUG sonia.scm.crowd.CrowdAuthenticationHandler - Crowd authenticate for user: <CROWD_USER>
19:43:37.727 [qtp2075530176-84] DEBUG sonia.scm.crowd.CrowdAuthenticationHandler - Crowd user: com.atlassian.crowd.integration.rest.entity.UserEntity@49826ea3[name=<CROWD_USER>,active=true,emailAddress=<CROWD_EMAIL>,firstName=<FIRST_NAME>,lastName=<LAST_NAME>,displayName=<FIRST_NAME> <LAST_NAME>]
19:43:37.788 [qtp2075530176-84] DEBUG sonia.scm.web.security.ChainAuthenticatonManager - authenticator sonia.scm.crowd.CrowdAuthenticationHandler ends with result, user: <CROWD_USER>, state: SUCCESS
19:43:37.789 [qtp2075530176-84] DEBUG sonia.scm.event.GuavaScmEventBus - post AuthenticationEvent{user=User{name=<CROWD_USER>, displayName=<FIRST_NAME> <LAST_NAME>, mail=<CROWD_EMAIL>, password=(not set), admin=false, type=crowd, active=true, creationDate=null, lastModified=null, properties={}}} to event bus
19:43:37.790 [qtp2075530176-84] DEBUG sonia.scm.security.ScmRealm - user <CROWD_USER> is member of <CROWD_GROUPS>
19:43:37.792 [qtp2075530176-84] TRACE sonia.scm.web.filter.BasicAuthenticationFilter - user <CROWD_USER> successfully authenticated

Comments (8)

  1. thiungoh

    Hi (OP here), thanks for your (extremely) quick reply.

    The actual version number (my bad) is 1.31. We're using version 1.5 of the Crowd plugin.

    Here is the relevant virtual host configuration:

    <VirtualHost *:443>  
        ServerName  <HOSTNAME>
        ServerSignature Off 
    
        # Logging.
        LogLevel warn
        ErrorLog /var/log/apache2/<HOSTNAME>-ssl-error.log  
        CustomLog /var/log/apache2/<HOSTNAME>-access.log combined  
    
        # SSL
        SSLEngine On  
        SSLCertificateFile      ssl/certs/<HOSTNAME>.pem
        SSLCertificateKeyFile   ssl/private/<HOSTNAME>.key
        SSLCACertificateFile    ssl/gd_bundle.crt
    
        # Reverse proxy routing.
        ProxyPreserveHost on
        ProxyRequests   off
    
        ProxyPass           /scm           ajp://<INTERNAL_IP>:8009/scm
        ProxyPassReverse    /scm           ajp://<INTERNAL_IP>:8009/scm
    </VirtualHost> 
    
  2. thiungoh

    We tried mod_proxy as well and it was the same story. Fortunately we were able to track down the problem. We had the following:

    RequestHeader unset Authorization
    

    in our Apache config. Removing this line fixed the issue.

    Thanks for your assisstance.

  3. Log in to comment