ShibbolethLogin

Shibboleth Login

It is said that the best way to learn is to teach someone else. Here is my chance of doing just that - learn as a I write this description of how to configure Shibboleth login for Roundup. And as I am learning, please feel free to correct me and offer suggestions on how to improve this description.

The Shibboleth login for Roundup is mostly about configuring Apache web server. The only configuration related to Roundup is to make sure that the http_auth in the tracker's config.ini [web] section is set to "yes" which is also the default value. The comment on this section states:

# Whether to use HTTP Basic Authentication, if present.
# Roundup will use either the REMOTE_USER or HTTP_AUTHORIZATION
# variables supplied by your web server (in that order).
# Set this option to 'no' if you do not wish to use HTTP Basic
# Authentication in your web interface.
# Allowed values: yes, no
# Default: yes
http_auth = yes

Setting http_auth = yes will ensure that Roundup will first try to use the Remote_User attribute before displaying the Roundup's built in Login page.

Roundup's documentation describes two different ways how Roundup could be served using Apache. The first option uses mod_python and is described in the Roundup installation documentation. This is the configuration I used to configure Shibboleth login.

The second option is documented in the FAQ and uses a proxy pass method - How do I put Roundup behind Apache? I imagine the Shibboleth login could also be implemented for the second option in a similar fashion.

In my case I have a Roundup tracker in /swadm/roundup/trackers/wcag. And I serve it using Apache using the following Apache virtual host:

####################################################################
#Roundup tracker - issues.mydomin.com                              #
####################################################################

<VirtualHost xxx.xxx.xxx.xxx:80>
   ServerName issues.mydomain.com
   RedirectPermanent / https://issues.mydomain.com/
</VirtualHost>

####################################################################
# Secure issues.mydomain.com                                       #
####################################################################

<VirtualHost xxx.xxx.xxx.xxx:443>
        ServerName      issues.mydomain.com

        AliasMatch ^/@@file(.*) /swadm/roundup/trackers/wcag/html$1
        AliasMatch ^/(?!Shibboleth.sso)(.*) /swadm/roundup/trackers/wcag/html/dummy.py/$1

        DocumentRoot    /swadm/roundup/trackers/wcag/html
        <Directory      /swadm/roundup/trackers/wcag/html>
                # Default allow policy
                Order Deny,Allow
        </Directory>

        <Location />
        AuthType shibboleth
        ShibRequestSetting requireSession 1
        Require valid-user
        RequestHeader set REMOTE-USER %{REMOTE_USER}s
        </Location>

        AddHandler      python-program .py
        PythonOptimize  On
        PythonPath      "sys.path + ['/usr/lib64/python2.6/site-packages']"
        PythonHandler   roundup.cgi.apache
        PythonOption    TrackerHome     /swadm/roundup/trackers/wcag

        SSLEngine on
        SSLCertificateFile /location/keyfile
        SSLCertificateKeyFile /location/certfile
        SSLCertificateChainFile /location/chaingfile
</VirtualHost>

There are couple things to note about this config.

I use fictitious domain name and replaced the ip numbers with xxx
I use generic words to describe the location of the SSL certificate files.
And most importantly. The line

AliasMatch ^/(?!Shibboleth.sso)(.*) /swadm/roundup/trackers/wcag/html/dummy.py/$1

is changed from the Roundup's configuration. In this line, the Shibboleth.sso is exempted from being directed elsewhere which is what is needed (Thanks Georg Lehner!)

The other parts of the Apache Virtual config should be familiar from either Roundup's documentation or from Shibboleth configurations that you may have worked on earlier.

Once Apache virtual configuration is configured, it is necessary to change the tracker's user names to the email format. Shibboleth returns the Remote_User value in the email format by default and the tracker's user names need to match that. Otherwise it would be necessary to configure Shibboleth to return just the username or manipulate the Remote_user value programmatically later.

The last item in the configuration is to change the Logout link in tracker's page.html file so that it performs the Shibboleth SP logout. At our institution this looks like this:

   <a href="https://issues.mydomain.com/Shibboleth.sso/Logout?return=https%3a%2f%2fidp2.shib.umn.edu%2fidp%2fLogoutUMN">Logout</a>
<!--
   <a href="#" tal:attributes="href python:request.indexargs_url('',
       {'@action':'logout'})" i18n:translate="">Logout</a>
-->
  </p>

Where I commented out the original page.html code. Now, I notice that the Logout is not working quite right. After I click on the Logout link, the browser displays a successful logout message delivered by Shibboleth, however when I enter issues.mydomain.com in the address bar, I am brought back presented with the list of issues without having to authenticate. The Logout link may need to be configured differently, but for now closing the browser will clear the login credentials.

Good luck with configuring Shibboleth Login!

Roundup Tracker

Shibboleth Login