Předpoklad pro správné splnění tohoto úkonu je platná registrace v rámci federace.

V konfiguračním souboru /etc/tomcat5.5/server.xml je potřeba nakonfigurovat tzv. konektor na propojení s mod_jk:

    <Connector port="8009" address="127.0.0.1"
               enableLookups="false" redirectPort="443" protocol="AJP/1.3"
               tomcatAuthentication="false" />

Vytvořte soubor /etc/tomcat5.5/workers.properties s obsahem:

worker.list=ajp13
worker.ajp13.type=ajp13
worker.ajp13.host=localhost
worker.ajp13.port=8009
worker.ajp13.lbfactor=50
worker.ajp13.cachesize=10
worker.ajp13.cache_timeout=600
worker.ajp13.socket_keepalive=1
worker.ajp13.recycle_timeout=300

Ujistěte se, že při startu Tomcat je správně nastaven proměnna JAVA_HOME, obzvlášť pokud máte nainstalované zároveň víc verzí JDK. V Debianu lze tuto proměnnou nastavit příslušnem „default“ souboru /etc/default/tomcat5.5.

Konfigurace mod_jk uložte do souboru /etc/apache2/mods-available/jk.conf:

<IfModule mod_jk.c>
  JkWorkersFile   /etc/tomcat5.5/workers.properties
  JkLogFile       /var/log/apache2/idp/mod_jk.log
  JkLogLevel      emerg
  JkMount         /shibboleth-idp/*       ajp13
</IfModule>

Tím deklarujeme, že dotazy s cestou /shibboleth-idp/* mají předávat přes konektor do aplikačního serveru Tomcat. Tyto cesty jsou pouze virtuální, neodráží žádné reálné adresáře, ale lze k nim vázat příslušné konfigurační direktivy (např. <Directory>).

Pokud ještě nemáte povolený modul mod_jk, povolte ho příkazem:

# a2enmod jk

Je potřeba nastavit přístup k virtuálním adresářům /shibboleth-idp/SSO a /shibboleth-idp/AA. Vzhledem k rozdílné povaze přístupu k nim je doporučitelné provozovat je na různých virtuálech. Běžně se SSO provozuje na standardním portu 443, zatímco AA běží pod zvláštním virtuálem na portu 8443.

V současné verzi Shibboleth IdP neni zahrnutá autentizace, komponenta SSO přebírá autentizaci, kterou ji poskytuje Apache. Jinými slovy, lze použít jakékoliv mechanismy, které využívají nastavení proměnné REMOTE_USER. V nejjednodušším případě to může být Apache autentizace:

<Location /shibboleth-idp/SSO>
	 AuthType Basic
	 AuthName "czTestFed login"
	 AuthUserFile /etc/httpd/conf/user.db
	 require valid-user
</Location>

V složitějších případech to může být externí single sign-on systém jako je napříkad Cosign:

  <Location /shibboleth-idp/SSO>
    CosignProtected               On
    CosignHostname                login.domena.cz
    CosignRedirect                https://login.domena.cz/
    CosignPostErrorRedirect       https://login.domena.cz/cosign/post_error.html
    CosignService                 shib
    CosignCrypto                  /etc/ssl/private/idp.domena.pem.key /etc/ssl/certs/idp.domena.cz.pem.crt /etc/ssl/certs

    AuthType                    Cosign
    Require                     valid-user
  </Location>

Detajlní informace ohledně integrace Shibboleth Idp se SSO funkcionalitou můžete získat ve zvláštním návodě.

Služba AA (Attribute Authority) poksytuje atributy přímo service providerům a proto vyžaduje klientskou autentizaci. Tím se liší od SSO služby, ke které přístupuje uživatel ze svého prohlížeče. Proto je dobré provozovat AA na zvlaštním virtuálu, do jehož konfigurace zapíšeme:

<IfModule mod_ssl.c>
<Location /shibboleth-idp/AA>
    SSLVerifyClient optional_no_ca
    SSLOptions +ExportCertData -StdEnvVars
</Location>
</IfModule>

Konfigurace je rozdělena do několika souborů:

• idp.xml - hlavní konfigurační soubor
• resolver.xml - definuje způsob získávání atributů k identitám
• arps.site.xml - definuje jaké atributy a za jakých podmínek budou vydávány

Soubory idp.xml a resolver.xml jsou běžně umístěné v konfiguračním adresáři (/etc/shibboleth), soubor arps.site.xml je v podadresáři arps/ (/etc/shibboleth/arps).

Pro snadnější začátek lze použít připravené šablony, kde je potřeba provést minimum změn, které nevyžadují hlubší porozumění konfiguračních mechanismů. Pro učely produkčního provozu však můžou být nedostatečné.

• idp.xml
• resolver.xml
• arp.site.xml

Doporučuje se ověřit si nejdříve funkcionalitu na co nejjednodušších případech konfiguračních souboru a až poté přistoupit k pokročilejšímu nastavení.

• idp.xml

Pro základní funkcionalitu stačí použít připravenou šablonu, kde je potřeba nastavit jen několik málo údajů:

• atribut providerId v elementu <IdPConfig> - hodnotu dostanete přidělenou při registraci
• nastavení cest ke klíči a certifikátu v elementu <Credentials>

V případě potřeby pokročilejších nastavení, řiďte se komentáři uvnitř šablony nebo si přečtěte dokumentaci.

• resolver.xml

Příklad nastavení, při kterém se atributy získávájí z LDAP (nejběžnější případ). Je potřeba nastavit správně <Property> elementy u data konektoru <JNDIDirectoryDataConnector>. Do šablony je také uveden tzv. statický data konektor, kde je možné rovnou definovat hodnoty atributů, které jsou pro všechny uživatele stejné, například název organizace.

Rozšířené možnosti nastavení atributů jsou popsány na wiki stránkách Internet2.

• arp.site.xml - příklad nastavení ARP, kdy se vyjmenované atributy vydávájí bez omezeni

Po registraci budou údaje o vašem IdP zaneseny do metadat, což je základní předpoklad pro to, aby se stal součástí federace. Stáhněte si aktuální metadata, umístěte je na vhodném místě (/etc/shibboleth) a ujistěte se, že máte k nim správně nastavenou cestu v konfiguračním souboru idp.xml.

Je žádoucí udržovat metadata aktuální. Shibboleth IdP v sobě neobsahuje funkcionalitu pro distribuci metadat. Tu je potřeba zajistit externími nástroji.

Po dokončení základní konfigurace lze přistoupit k testování.

Pozn. tomcat - vypnout security, nastavit prava pro logovaci adresar