====== 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 [[http://www.bestpractical.com/rt/ | 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 [[http://www.cpan.org/ | 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 [[http://wiki.bestpractical.com/view/MigrateToNewServer | 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 //Configuration// -> //Global// -> //User 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: AuthType shibboleth require shibboleth ShibRequireSession on 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í.