Authentication when behind a reverse proxy

[William Gallafent]

Hi All,

Looking forward to getting my first gitit server up and running. I think I'm quite close, but am having trouble getting authentication / login to work.

I have configured the server to be behind a reverse proxy using apache, as described in the instructions. It's at the (example, domain name changed!) address https://my.server:12345/gitit/ .

I am now able to see the default front page at that address.

I would now like to use information from the client certificate (which my server demands, so the information is always available) to set the login credentials for the wiki. I have set the requirement for login to be “modify” so that editing pages requires a login. If I set require-authentication to “none”, I am able to edit the page anonymously. Note that even with this “none” setting, I do not see a login button on the front page … might this be related to http://code.google.com/p/gitit/issues/detail?id=73 ? Even accessing the wiki locally rather than via the reverse proxy does not display a login button.

Accordingly, I have been playing with the authentication-method setting in the gitit config. So far, both ways I've tried have failed:

First way, “generic”:

Within the gitit config, I set the authentication-method to be generic. This indicates that the REMOTE_USER environment variable should be used as the login name.

Within the “<Location /blah/>” element of my apache config, I add the following line:

    SSLUserName SSL_CLIENT_S_DN_CN

This /may/ set the environment variable REMOTE_USER, but I'm not completely clear about that. I have therefore also tried using a SetEnv to set that variable directly, but the result is the same.

This leads to the following error when I click the link from the default front page to edit it (The URI is https://my.server:12345/gitit/_login?destination=%2F_edit%2FFront%2520Page ):

“

Happstack 6.6.3

Your file is not found
To try again is useless
It is just not here”

Second way:

Within the gitit config, I set the authentication-method to be http. This indicates that the “Authorization” header should be used to provide the login name.

Within the “<Location /blah/>” element of my apache confic, I add the following line:

RequestHeader set Authorization "%{SSL_CLIENT_S_DN_CN}s"

When I click on the link in the line “There is no page 'Front Page'. You may create the page by clicking here.” though, I get into an infinite redirect loop: According to firebug the browser bounces with a 303 and a 307 between

https://my.server:12345/gitit/_login?destination=%2F_edit%2FFront%2520Page

and

https://my.server:12345/gitit/_edit/Front%20Page

… each redirects to the other.

So, in short, what am I doing wrong? I'm not sure whether this is a problem in my apache config, gitit config, or gitit itself!

My hope is that once gitit can genuinely see the user name in some way universally, the login redirect will /work transparently/ and I'll be automagically logged in and taken to the edit page. It feels as if the second way is closer, since the _login function is forwarding me to the _edit function, suggesting that _login thinks I /am/ authenticated … but then _edit is bouncing me back to _login because _edit thinks I'm /not/ authenticated!

I'm using apache2.2.22-1ubuntu1 and gitit 0.9-1ubuntu1 of ubuntu 12.04.4.

Any help would be very welcome, it feels so close! Any working recipes also fine, I can dig through to match the necessary bits to my config.

[William Gallafent]

​Small update: I realised that the for “second way”, the Authorization header needs to be correctly formatted of course, my original approach is completly wrong-headed.

I therefore tried to achieve this by using the +FakeBasicAuth option for SSLOptions (which should create an Authorization header with the DN from the certificate encoded as the username), and by adding a “SetEnv proxy-chain-auth On”. Same bouncing between _login and _edit occurs though.

I have also noticed that I'm seeing lines like the following in my apache logs, but this is a red herring w.r.t. my auth problems I think:

[Tue Feb 11 19:06:37 2014] [error] [client 1.2.3.4] File does not exist: /var/www/_user, referer: https://my.server:12345/gitit/

The fix for this is to add the following line to the proxy configuration:

ProxyHTMLExtended On

(This allows the html proxy to change paths in e.g. Javascript, as well as html. Remains to be seen whether or not this causes other problems!)

Thanks again for any help with the auth stuff …

[William Gallafent]

… and, to answer my own question:

The answer is to use the “generic” authentication approach in gitit, and to configure apache to set the REMOTE_USER value /in the headers/ for the reverse proxy's request:

    RequestHeader set REMOTE_USER "%{SSL_CLIENT_S_DN_CN}s"

​Is there somewhere I could document this recipe for future reference?

[John MacFarlane]

+++ William Gallafent [Feb 11 14 22:46 ]:

Glad you figured it out! If you want to suggest a modification to the
instructions in the README, just send me a diff.

John

[Michael Ambrus]

Hello, I'm new to gitit and I'm not sure if the following is an alternative to, or the same as mentioned in this thread. It's in practice a meld of information from various Apache module pages and from gitit:

==========================================================
Listen 2443
<VirtualHost *:2443>
    ServerName yourserver.domain
    DocumentRoot /var/www
    ServerAdmin name@domain
    SSLEngine on
    SSLCertificateFile  /etc/ssl/apache/seldlx0294.corpusers.net.crt
    SSLCertificateKeyFile /etc/ssl/apache/seldlx0294.corpusers.net.key
    SSLInsecureRenegotiation off

    RewriteEngine On
    ProxyPreserveHost On
    ProxyRequests Off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyPass /wiki/ http://127.0.0.1:5001/

    <Location /wiki/>
        SetOutputFilter  proxy-html
        ProxyPassReverse /
        ProxyHTMLURLMap  /   /wiki/

        RequestHeader unset Accept-Encoding
        SSLVerifyDepth       5  
        SSLOptions           +FakeBasicAuth
        SSLRequireSSL
        AuthName             "Certificate user-textAuthentication - wiki"
        AuthType             Basic
        AuthBasicProvider    file
        AuthUserFile         /path/to/wiki.passwd
        Require              valid-user
    </Location>
 
    ErrorLog /var/log/apache2/error.log
    LogLevel warn
 
    CustomLog /var/log/apache2/access.log combined
    ServerSignature On
</VirtualHost>

SSLVerifyClient      none
SSLCACertificateFile /path/to/conf/ssl.crt/ca.crt
SSLCACertificatePath /path/to/conf/ssl.crt
==========================================================

This requires some fiddling with creating (self-signed) certificates and loading of required modules. Benefit is that the setup, credentials e.t.c. can be reused and possibly shared among other services (gitits and others) and makes maintenance easy. Note that the listening port can be any, including 443 (default https).

The setup seems to work very well for our needs and requires nothing from gitit besides starting gitit with the -l option. If any drawbacks can be detected, please let us know. I.e. gitit should be started:

gitit -l 127.0.01 <any_other_options>

Hence gitit can't respond to any connections on any physical interfaces, effectively blocking 5001 or any other it was started with, except from internal requests (Apache daemon in this case).

[William Gallafent]

Hi Michael,

I also use client certs to identify and authorise users in various different sites and applications served by the same apache instance. I too find it a very convenient way to control access by different groups of users to the various services which are running.

Each location served by apache uses different SSL configuration options to define who is and isn't allowed access to it. The main thrust of my work here with gitit was to automate the identification and log-in of users to gitit using information from their client certificates.

With my config, there are no login/register links visible in the gitit world. Each user is automatically considered to be identified and authorised by the webserver before being passed to gitit. The advantage is that the username as used by gitit e.g. to identify who made an edit can be set flexibly from information in the cert. I now have this in my <Location /wiki/> section:

    RequestHeader set REMOTE_USER "%{SSL_CLIENT_S_DN_CN}s of %{SSL_CLIENT_S_DN_O}s"

…this means that edits are automatically attributed to e.g. “William Gallafent of Sunway Systems".

No need for users to register or login for the wiki: apache handles their identification and authentication, and passes their “name” to gitit in a way it understands (once its auth method is set to “generic” so it reads the username from the REMOTE_USER header). I control who has access to the wiki via apache's config.

Does your config manage the same automatic identification of users within gitit, or do users still need to register and login using the forms?

What I haven't done yet is tiered access … time will come when I want some people (or people from some organisations, for example) to have edit access, others only read access … for example. More reading and experimentation required before I can achieve that I think!

--
Bill Gallafent.

[Michael Ambrus]

Hi Bill,

We don't use any forms, but the equivalent I suppose: All registrations are made manually, passwords are self-ciphered and stored on file. This works as long as the number of intended users are manageable (less than ~50).

Do I understand your set-up correctly: the holder of a specific (i.e. unique) certificate is using it as a way to authorize himself? How do you make certain the correct certificate reaches the intended user (or browser) the first time? Can the certificate creation be automated?

Regards

/Michael

~-~ ~-~ ~-~ ~-~
Best Regards
Michael Ambrus
PGP key

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

--
You received this message because you are subscribed to a topic in the Google Groups "gitit-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gitit-discuss/yr77c5_8szI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gitit-discus...@googlegroups.com.
To post to this group, send email to gitit-...@googlegroups.com.
Visit this group at http://groups.google.com/group/gitit-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[William Gallafent]

On 12 February 2014 15:12, Michael Ambrus <ambr...@gmail.com> wrote:

Do I understand your set-up correctly: the holder of a specific (i.e. unique) certificate is using it as a way to authorize himself?

Yes, both identify and authorise (the server checks the certificate chain of the presented client cert). Each user has an unique client cert.

 

How do you make certain the correct certificate reaches the intended user (or browser) the first time?

By meeting the individual in person and handing over the cert on a physical medium (!) or (more often) by transmitting the certificate pkcs12 bundle by email, encrypted with a strong password which is given by telephone or some other secure non-email means.

Can the certificate creation be automated?

Anything's possible ;)

At the moment though, the site's user base is sufficiently small that I generate each user's certificate by hand using openssl (or a small makefile which runs the necessary sequence of openssl commands to generate it). This procedure could certainly be automated, and will be, if we end up with more users!