OTRS is the Open-source Ticket Request System, which is a Perl application that runs on an Apache web server. OTRS has two different web interfaces:
- The customer interface. This is for people who submit tickets.
- The agent interface. This is for people working on tickets ('admins' if you will)
OTRS can use various authentication methods, such as a local database, or Active Directory/LDAP. It is also possible to use external authentication, in which case OTRS does not take responsibility for authentication any more, but instead relies on Apache environment headers to provide a username. The is the way forward if you want to use SAML or federated authentication, but there are some issues with.
The biggest issue is that is not possible to provision accounts for customers in OTRS before they have logged in. This is because there is no way of knowing a user's details until they have authenticated. To overcome this I wrote two authentication modules for OTRS.
Below is the recipe for getting OTRS to work with federated authentication using Ubuntu 14.04, OTRS 3.3.8 and mod_auth_mellon 0.7. If you manage to implement it on another combination of software, please let me know.
Prerequisites
Before you start, make sure you have these bits in place:
- A correctly configured Apache web server that is able to serve an HTTPS web site (https://otrs.example.com).
- A SAML Identity Provider (IdP).
- An account on that IdP.
- An attribute that can be used as username in OTRS (for example eduPersonPrincipalName). Attributes for first name, last name, and e-mail are optional but highly recommended as the service would be pretty useless without these. In this case we assume that 'givenName', 'sn', and 'mail' can be used.
- The user name of the to-be administrator account. So, if you choose eduPersonPrincipalName as the attribute for username, you need to know your own value (for instance 'dvisser@surfnet.nl').
OTRS
Go to https://www.otrs.com/try/, scroll to Source, and pick the latest version of OTRS Help Desk.
Follow the instructions at http://otrs.github.io/doc/manual/admin/stable/en/html/index.html, do a standard install and make sure everything works.
Pay special attention to the phrase "Please install OTRS from source, and do not use the OTRS packages that Debian/Ubuntu provides." 
It will require some fiddling to get all the Perl modules sorted, I suggest to use the packages modules as much as possible.
The docs all seem to assume that you'd want to run OTRS inside a subdirectory (https://example.com/otrs), but we want it to be the root of our vhost (https://otrs.example.com), in which case this configuration is a little bit different, see below (you should have the HTTPS stuff already configured, probably in /etc/apache2/mods-enabled/ssl.conf):
ServerName otrs.example.com
Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/"
Alias / "/opt/otrs/bin/cgi-bin/"
<IfModule mod_perl.c>
# Setup environment and preload modules
Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl
# Reload Perl modules when changed on disk
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
# mod_perl2 options for GenericInterface
<Location /nph-genericinterface.pl>
PerlOptions -ParseHeaders
</Location>
</IfModule>
<Directory "/opt/otrs/bin/cgi-bin/">
AllowOverride None
DirectoryIndex customer.pl
AddHandler perl-script .pl .cgi
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
PerlOptions +SetupEnv
# mod_auth_mellon placeholder
<IfModule mod_version.c>
<IfVersion < 2.4>
Order allow,deny
Allow from all
</IfVersion>
<IfVersion >= 2.4>
Require all granted
</IfVersion>
</IfModule>
<IfModule !mod_version.c>
Order allow,deny
Allow from all
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/javascript text/css text/xml application/json text/json
</IfModule>
</Directory>
<Directory "/opt/otrs/var/httpd/htdocs/">
AllowOverride None
<IfModule mod_version.c>
<IfVersion < 2.4>
Order allow,deny
Allow from all
</IfVersion>
<IfVersion >= 2.4>
Require all granted
</IfVersion>
</IfModule>
<IfModule !mod_version.c>
Order allow,deny
Allow from all
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/javascript text/css text/xml application/json text/json
</IfModule>
# Make sure CSS and JS files are read as UTF8 by the browsers.
AddCharset UTF-8 .css
AddCharset UTF-8 .js
# Set explicit mime type for woff fonts since it is relatively new and apache may not know about it.
AddType application/font-woff .woff
</Directory>
<IfModule mod_headers.c>
# Cache css-cache for 30 days
<Directory "/opt/otrs/var/httpd/htdocs/skins/*/*/css-cache">
<FilesMatch "\.(css|CSS)$">
Header set Cache-Control "max-age=2592000 must-revalidate"
</FilesMatch>
</Directory>
# Cache css thirdparty for 4 hours, including icon fonts
<Directory "/opt/otrs/var/httpd/htdocs/skins/*/*/css/thirdparty">
<FilesMatch "\.(css|CSS|woff|svg)$">
Header set Cache-Control "max-age=14400 must-revalidate"
</FilesMatch>
</Directory>
# Cache js-cache for 30 days
<Directory "/opt/otrs/var/httpd/htdocs/js/js-cache">
<FilesMatch "\.(js|JS)$">
Header set Cache-Control "max-age=2592000 must-revalidate"
</FilesMatch>
</Directory>
# Cache js thirdparty for 4 hours
<Directory "/opt/otrs/var/httpd/htdocs/js/thirdparty/">
<FilesMatch "\.(js|JS)$">
Header set Cache-Control "max-age=14400 must-revalidate"
</FilesMatch>
</Directory>
</IfModule>
The site is now configured so that the bare URL will go to the customer interface. This makes the most sense because typically customers will have less clue about where to go.
The agent interface is where you should log in to with the default root@localhost account.
Once you're in, you should create a new agent with full permissions, and make sure the username is your eduPersonPrincipalName.
mod_auth_mellon
mod_auth_mellon is an Apache module, which is available in Ubuntu 14.04 and later. To get this working with Ubuntu 12.04, I recompiled the Debian source packages from the University of Tilburg and made them available in our own APT repository. Either way, it's easy to install:
apt-get install libapache2-mod-auth-mellon a2enmod auth_mellon
Create a directory /etc/apache/mellon, and store the Identity Provider metadata in XML format to a file called idp.xml.
Create the cryptographic material for mod_auth_mellon:
openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout sp.key -out sp.crt
Now add this to the configuration of the vhost at the mod_auth_mellon placeholder:
MellonEnable "info"
MellonSecureCookie On
MellonSessionDump Off
MellonSamlResponseDump Off
MellonEndpointPath "/mellon"
MellonSPPrivateKeyFile /etc/apache2/mellon/sp.key
MellonSPCertFile /etc/apache2/mellon/sp.crt
MellonIdPMetadataFile /etc/apache2/mellon/idp.xml
# To avoid security holes, first unset any existing header
RequestHeader unset eduPersonPrincipalName
# Then conditionally set it
RequestHeader set eduPersonPrincipalName "%{MELLON_eduPersonPrincipalName}e" env=MELLON_eduPersonPrincipalName
As you can see, the attribute eduPersonPrincipalName is being used as the username. This is the attribute that should always be send by the IdP.
I had problems getting things to work if the environment variable was REMOTE_USER. I think there is some issue with mod_auth_mellon trying to overwrite that, but I didn't have time to find the cause. It worked with everything else than REMOTE_USER though 
By this time, you should be able to download the Service Provider metadata from https://otrs.example.com/mellon/metadata, and use it to add it to your IdP, thereby creating a trust relationship.
Once that is done, you should be able to authenticate by going to https://otrs.example.org/mellon.
Adding the new methods to OTRS
Download the archive containing the methods and unpack it over your OTRS tree. It contains two files, both called HTTPBasicAuthMellon.pm, which go into System/Kernel/Auth and System/Kernel/CustomerAuth.
Once they're there, change your configuration (System/Config.pm) to include these statements:
# Customer
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuthMellon';
# Customer user are automagically created (auto-provisioned) using the environment vars below
$Self->{'Customer::AuthModule::HTTPBasicAuthMellon::UsernameEnvVar'} = 'MELLON_eduPersonPrincipalName';
$Self->{'Customer::AuthModule::HTTPBasicAuthMellon::MailEnvVar'} = 'MELLON_mail';
$Self->{'Customer::AuthModule::HTTPBasicAuthMellon::FirstNameEnvVar'} = 'MELLON_givenName';
$Self->{'Customer::AuthModule::HTTPBasicAuthMellon::LastNameEnvVar'} = 'MELLON_sn';
$Self->{'CustomerPanelLoginURL'} = 'https://otrs.example.com/mellon/login?ReturnTo=/customer.pl';
$Self->{'CustomerPanelLogoutURL'} = 'https://otrs.example.com/mellon/logout?ReturnTo=http://www.terena.org';
# Because auto-provisioned users will all have the same e-mail address
$Self->{CustomerUser}->{CustomerUserEmailUniqCheck} = 0;
# Agents are NOT auto-provisioned. The will have to be created manually.
# To find their username, they could first log in as a customer, so that you can see their username
# in the Customer User Manager overview.
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuthMellon';
# Only this one is needed
$Self->{'AuthModule::HTTPBasicAuthMellon::UsernameEnvVar'} = 'MELLON_eduPersonPrincipalName';
$Self->{'LoginURL'} = 'https://otrs.example.com/mellon/login?ReturnTo=/index.pl';
$Self->{'LogoutURL'} = 'https://otrs.example.com/mellon/logout?ReturnTo=http://www.terena.org';
At this point, you should be able to log in to the site as an admin with your new account.
If you log in to the customer page, your account will be automatically created.
I don't even trust my own Perl skills, so use all of this with care