cs:tech:apps:rt

Request Tracker pro Shibboleth

Tento dokument je primárně určen správcům systému Request Tracker, kteří hodlají systém používat ve federativním prostředí.

Aplikací určenou k vyzkoušení převodu pod Shibboleth byl Request Tracker (RT) – systém pro sledování a správu uživatelských požadavků. Následující úpravy byly prováděny na serveru s instalovaným operačním systémem Linux Debian – byla použita současná stable verze Lenny 5.0.4 – s funkčním Shibboleth Native Service Provider. Dále předpokládáme instalovaný systém RT s funkční konfigurací pro databázový backend některého z RT systémem podporovaných RDBMS.

Service Provider by měl od Identity Providerů získávat následující minimální množinu atributů:

  • eduPersonPrincipalName – login uživatele s identifikací organizace (scoped attribute) – příklad: „indy@zcu.cz“
  • cn (common name) – jméno uživatele – příklad „Petr GROLMUS“
  • mail – e-mailovou adresu uživatele v organizaci – příklad „indy@civ.zcu.cz“

Při znalosti výše uvedených atributů je možné vytvořit standardní účet uživatele systému Request Tracker.

RT systém je velmi přehledně zpracován ve frameworku Mason jazyka Perl. První experimenty s „shibbolethizací“ a využitím přetížení hlavního masonského autohandleru RT systému se ukázaly jako velmi těžkopádné. Do skriptu bylo nutné přidat kompletní logiku pro získávání atributu, vytváření nových účtů v RT a provedení automatického přihlášení uživatele. Nakonec bylo využito elegantní řešení s využitím existujícího CPAN (Comprehensive Perl Archive Network) balíku RT::Authen::ExternalAuth běžně využívaného pro ověřování proti službě LDAP. Podporu pro Shibboleth je nutné do tohoto balíku zakomponovat, nicméně změny jsou minimální a již máme připravenou logiku vytváření nového uživatelského účtu.

Pokud již máme někde existující RT systém, pak zřejmě budeme potřebovat zkopírovat obsah současné databáze na nový stroj. Tento úkon je velmi dobře popsán na stránkách vývojářů. Než přikročíme k „shibbolethizaci“ aplikace, pak potřebujeme provést dva důležité kroky

  • změna uživatelských jmen
  • nastavení superuživatele RT

Pokud plánujete zprovoznění nového RT systému bez existujících uživatelských účtů, pak krok změny uživatelských účtů můžete směle přeskočit. V opačném případě lze předpokládat, že přihlašovací jména přes Shibboleth budou odlišná od dosavadně používaných. Pokud ovšem neprovedete změnu stávajících user names a uživatelé se budou přihlašovat novým způsobem (přes Shibboleth), který předá jejich user name v odlišném formátu, pak uživatel ztratí historii svých dřívějších ticketů. Pro systém RT totiž půjde o dvě zcela různé identity, které si vzájemně nevidí (resp. neměly by vidět) svá data. Navíc nedojde k přenosu aktuálně nastavených práv na záznam vytvořený při prvním přístupu uživatele přes Shibboleth. Proto lze pro RT systém s již provozními daty změnu user names jen doporučit.

V našem testovacím případě na Západočeské univerzitě uživatelé přistupují do RT systému s krátkým uživatelským jménem. Při použití Shibbolethu bude uživatelské jméno oproti dosavadnímu rozšířeno o scope doménu. Tj. například původní uživatelské jméno indy bude po přihlášení přes Shibboleth ve formátu indy@zcu.cz. Tuto změnu uživatelských jmen jde v databázi snadno provést hromadně SQL dotazem provedeným v databázi RT systému:

   update Users set Name = concat(Name, '@zcu.cz') where Name not like "%@%";

Podmínka za where nám změnu omezí jen na „interní“ uživatelská jména, zatímco uživatelské údaje nasbírané z kontaktů přes e-mailové rozhraní RT zůstanou nedotčeny.

Nyní je na čase zvolit uživatele, kterému budou nastavena superuživatelská práva v RT systému. Změnu v konfiguraci RT provedeme v ConfigurationGlobalUser Rights, po zobrazení výčtu všech uživatelů, najdeme ten správný (nebo několik správných), u kterého zaklikneme právo Super User. Změnu musíme potvrdit dole na stránce kliknutím na tlačítko „Modify User Rights

Nyní již přikročíme k nezbytným úpravám konfigurace RT a zdrojových kódů. Nejprve ze stránek CPANu stáhneme a zkompilujeme balík RT::Authen::ExternalAuth:

   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

Skript se vás dotáže na cestu k souboru RT.pm – v případě balíkové distribuce v Debianu je jeho umístění v /usr/share/request-tracker3.6/lib. Kompilaci a instalaci balíku dokončíme:

   make
   make install

Jelikož balík je standardně připraven pro spolupráci s LDAPem, tak budeme muset obdobným způsobem ze stránek CPANu stáhnout a nainstalovat i balík NET::LDAP. Balík RT:Authen-ExternalAuth byl nainstalován do adresáře /usr/local/share/request-tracker3.6/lib/RT/, respektive do podadresáře Authen. Než provedeme změny v tomto balíku, připravíme konfiguraci RT systému pro spolupráci s Shibbolethem. RT systém je navržen tak, aby kromě vlastních autentizačních dat uměl standarně přebírat identitu uživatele od webserveru, a proto získávání identity od autentizačního modulu Apache pro Shibboleth nepředstavuje žádné zvýšení bezpečnostního rizika. Je pouze nutné dbát na to, aby RT systém byl provozován v adresáři chráněném autentizačním modulem pro Shibboleth – viz dále.

Do souboru /etc/request-tracker3.6/RT_SiteConfig.pm vložíme direktivy, které RT řeknou, že má důvěřovat externí autentizaci webserveru:

   Set($WebExternalAuth , 1);
   Set($WebFallbackToInternalAuth , true);
   Set($WebExternalAuto , 1);

Dále do stejného souboru přidáme direktivy pro nově instalovaný modul, které určují jednak mapování atributů poskytnutých IdP do položek uživatelských účtů RT:

   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' }
           }
       }
   );

Jelikož instalovaný balík standardně nerozumí, jakým způsobem má zpracovávat údaje pro Shibboleth a také neumí běžně pracovat s proměnnými prostředí, tak jak nám je připraví Shibboleth SP, tak musíme provést poslední změnu, a to přímo ve zdrojovém kódu instalovaného balíku RT::Authen::ExternalAuth. Změnu provedeme v souboru /usr/local/share/request-tracker3.6/lib/RT/Authen/ExternalAuth.pm. V kódu tohoto souboru nalezneme řádek

   if($config->{'type'} eq 'ldap'){

tento řádek změníme na:

   elsif($config->{'type'} eq 'ldap'){ 

Těsně před tuto změnu nakopírujeme následující kód, který při použití Shibbolethu bude umět použít hodnoty uložené v proměnných prostředí:

     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;
         }       
     }

Nyní již zbývá jen správně nastavit webserver Apache, aby při přístupu k systému RT byla použita autentizace Shibboleth:

  <Location /rt/>
      AuthType shibboleth
      require shibboleth
      ShibRequireSession on
  </Location>

Posledním krokem je pak restart webserveru:

   /etc/init.d/apache2 restart

Nyní je systém Request Tracket plně připraven pro nasazení ve federovaném prostředí.

Poslední úprava:: 2017/02/10 07:02