Request Tracker for Shibboleth
CESNET technical report 7/2010
Petr Grolmus
University of West Bohemia
Received 31.05.2010
Abstract
Shibboleth is a software package produced by the Internet2 Consortium to enable Single Sign-on (SSO) authentication for users in an environment composed of multiple organizations. Splitting Shibboleth into two parts – the Identity Provider (IdP) and the Service Provider (SP) – allows for separation of responsibilities and their assignment to individual participants. Home IdPs collect information (attributes) on their own users, provide authentication services for those users, and send pre-determined sets of attributes to the SP. As indicated by its title, an SP provides a service; authorized access to that service is allowed to users based on attributes received from IdPs. Any Web application can be seen as an example of such a service. This Report explains how to integrate Shibboleth with frequently used multi-user application such as Request Tracker.
Keywords: Shibboleth, Identity Provider, IdP, Service Provider, SP, Single Sign-On, SSO, authentication, authorization, Request Tracker
1 Request Tracker for Shibboleth
Request Tracker1; (RT) – a system for monitoring and managing user requests – was yet another product we have integrated with Shibboleth authentication. Configuration changes presented below were done on a server running Debian Linux2 with the Shibboleth Native Service Provider already installed. We also assume that the server has RT installed, and that there is a configured database backend supported by RT.
The minimum set of attributes the Service Provider needs to receive from Identity Providers is as follows:
- eduPersonPrincipalName – user name and home organization (scoped attribute), e. g.
indy@zcu.cz, - cn (common name) – full name of the user, e. g.
Petr GROLMUS, - mail – user's e-mail address within the
organization, e. g.
indy@civ.zcu.cz.
Knowing the attributes listed above, RT is able to create a standard user account for that user.
The RT System has been implemented in Perl's Mason framework. Our initial experiments with Shibboleth integration, based on overloading Mason's main autohandler for the RT System, have shown that such approach can be quite cumbersome. The script had to be extended with extensive logic to extract the attributes, create RT accounts, and log users in automatically. In the end, we have identified an existing RT::Authen::ExternalAuth package available from CPAN (Comprehensive Perl Archive Network). The module is typically used to provide LDAP-based authentication in RT. Shibboleth support had to be integrated into that package, but the changes are few and functions required for user account creation are already there.
In case there already is an existing installation of RT, we may need to copy the contents of its database to the new installation. The process is very well documented at the Developers' Web. After that, we may proceed with Shibboleth integration. There are two steps that need to be taken:
- Changing user names
- Setting up RT superusers
Unless you want to preserve user accounts that currently exist in RT, you may safely skip step 1. In the other case, it is reasonable to expect that user names used for Shibboleth authentication will differ from the preexistent ones. Unless we modify existing user names for users who are going -- from now on -- to access the system with Shibboleth, which would provide their names in a different format, the users are bound to lose the history of their old tickets. RT will treat them as two separate identities who are not allowed (or should not be allowed) to see each other's data. Similarly, access rights will not be copied from the old accounts to new identities created once the users start to access RT through Shibboleth. That is why changing user names is highly recommened in all RT installations containing production data.
At the University of West Bohemia, users access the RT using their short user names. With Shibboleth, those names are extended with their “scope”, i. e. the organization's domain. That means, for instance, that original user name indy will appear as indy@zcu.cz if we use Shibboleth for authentication. User names stored in the RT database may be modified accordingly by calling a singe SQL query:
update Users set Name = concat(Name, '@zcu.cz') where Name not like "%@%";
The where clause limits selection to “internal” user names, leaving contacts acquired through RT's e-mail interface intact.
At this point, we need to select user accounts to be granted with RT superuser privileges. The change is done by clicking Configuration -> Global -> User Rights, finding the respective user accounts and checking the Super User option. When done, confirm the change by clicking “Modify User Rights” on the bottom of the page.
On top of relying on its own authentication data, RT has been designed to accept user identities from web servers, which is why accepting user identities provided by the Shibboleth authentication module for Apache does not reduce security in any way. It is necessary, though, to make sure that RT runs in a directory protected by Shibboleth authentication -- see bellow.
We are now ready to proceed with the necessary modifications to RT configuration and source code. Start with downloading the RT::Authen::ExternalAuth package from CPAN and compiling it:
cd /tmp wget http://search.cpan.org/CPAN/authors/id/Z/ZO/ZORDRAK/RT-Authen-ExternalAuth-0.08.tar.gz tar -zxvf RT-Authen-ExternalAuth-0.08.tar.gz cd RT-Authen-ExternalAuth-0.08.tar.gz perl Makefile.PL
The script asks for a path to file RT.pm, which – if installed from a Debian package – will be located in /usr/share/request-tracker3.6/lib. Finish compilation by running:
make make install
Since the external authentication package has been originally developed for LDAP authentication, we will also need to download and install the “NET::LDAP” package from CPAN. Package RT:Authen-ExternalAuth is installed in the directory /usr/local/share/request-tracker3.6/lib/RT/ or, more specifically, in its Authen subdirectory. Modification of that package will be required but prior to that, RT needs to be configured to cooperate with Shibboleth correctly.
Insert the following directives into /etc/request-tracker3.6/RT_SiteConfig.pm to make sure that RT trusts the webserver's external authentication:
Set($WebExternalAuth , 1); Set($WebFallbackToInternalAuth , true); Set($WebExternalAuto , 1);
Directives to determine mapping of attributes provided by the IdP to mandatory user attributes within the RT system must also be included in the same configuration file:
Set($ExternalAuthPriority, []);
Set($ExternalInfoPriority, [ 'Shibboleth' ]);
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 0);
Set($ExternalSettings,
{ 'Shibboleth' =>
{ 'type' => 'shib',
'auth' => 0,
'info' => 1,
'attr_match_list' =>
[ 'Name', 'EmailAddress', 'RealName' ],
'attr_map' =>
{ 'Name' => 'REMOTE_USER',
'EmailAddress' => 'mail',
'RealName' => 'cn' }
}
}
);
By default, the newly installed package neither knows how to process data for Shibboleth, nor does it interpret environment variables set by Shibboleth SP. That is why another change is required in the source code of the RT::Authen::ExternalAuth package. More specifically, the change must be done in /usr/local/share/request-tracker3.6/lib/RT/Authen/ExternalAuth.pm. Search for the following line in the code:
if($config->{'type'} eq 'ldap'){
Then replace that line with:
elsif($config->{'type'} eq 'ldap'){
Also, the segment of code shown below must be copied right in front of the modified line. It makes sure that when using Shibboleth, RT will be able to read and use the values of environment variables:
if ($config->{'type'} eq 'shib') {
my $currentUser = undef;
my $paramHash = {};
for (keys(%{$config->{attr_map}})) {
my $envVar = $config->{attr_map}->{$_};
$RT::Logger->debug("Checking environment for $value ($envVar)");
$paramHash->{$_} = $ENV{$envVar};
if (($key eq $envVar) && (lc($value) eq lc($ENV{$key}))) {
$RT::Logger->debug("Found $envVar match for current user");
$currentUser = 1;
}
}
if ($currentUser) {
$found = 1;
%params = %$paramHash;
}
else {
next;
}
}
Now, all we need to do is set up the Apache webserver to use Shibboleth authentication when accessing RT:
<Location /rt/> AuthType shibboleth require shibboleth ShibRequireSession on </Location>
Finally, restart the webserver:
/etc/init.d/apache2 restart
At this point, RT is fully prepared for use in a federated environment.
Footnotes:
| 1. | http://www.bestpractical.com/rt/ |
| 2. | using the most recent stable version Lenny 5.0.4 |