Shib2IdpInstall

entityID
Fontos, hogy az entityID egyedi és állandó legyen. Javasolt forma:  .

Tűzfal
Be kell engedni a 443-as és a 8443-as portokat. Ha nagyon szigorúan vesszük, akkor a 8443-as portot elegendő csak a szóbajöhető SP-kről beengedni, de ezzel általában nem vagyunk tisztában, ezért célszerű a "nagyvilágból" beengedni. Biztonsági szempontból nem sok különbség van a 443-as és a 8443-as porton elérhető alkalmazások között.

JDK
Debian Lenny alatt a  csomagot kell feltelepíteni. Telepítés előtt érdemes az aptitude-ban kikapcsolni az opcionális függőségek telepítését.

aptitude install sun-java6-jdk

Állítsuk be, a  környezeti változót! export JAVA_HOME=/usr/lib/jvm/java-6-sun

Shibboleth security provider
Be kell másolni a  állományt a   könyvtárba. Ha az   könyvtár nem létezik, akkor hozzuk létre. cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext

Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a  fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort: security.provider.7=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
 * Megj.: a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!

Bouncy Castle JCE
A JVM-mel jövő Java Cryptography Engine (JCE) nem támogatja az összes kriptográfiai algoritmust, amelyre az Identity Providernek szüksége lehet (pl. XML Digital Signature, XML Encryption). A Bouncy Castle JCE ezek mellett még olyan algoritmusokat is tartalmaz (általában hatékonyabb és szabványosabb formában), amelyek benne vannak a Java JCE-ben.

Ehhez először le kell tölteni a Bouncy Castle JCE-t. A JCE állományok a Provider oszlopban, a "Signed Jar Files" részben találhatók. (A nevük .) Letöltés után a .jar fájlokat a   könyvtárba kell tenni.

wget http://www.bouncycastle.org/download/bcprov-jdk15-141.jar cp bcprov-jdk15-141.jar $JAVA_HOME/jre/lib/ext

Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a  fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort: security.provider.8=org.bouncycastle.jce.provider.BouncyCastleProvider
 * Megj.: a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!

Tomcat 6
A 2.1.3 és újabb IdP megköveteli a Tomcat6 használatát (Tomcat5.5 -tel bizonyos böngészők esetén nem működik rendesen). A Debian Lenny nem tartalmazza a Tomcat6-ot, ezért a testing ágból kell feltelepíteni.

A Tomcat6-ra való frissítésről további - vázlatos - információkkal ez az oldal szolgál.

Telepítés
Ha minden rendben meg, és a squeeze source beállításra került, akkor elegendő egy aptitude install tomcat6 parancs kiadása. Ez felpakolja a tomcat különböző függőségeit is - az ajánlott függőségek (tomcat6-admin, -docs, stb.) feltelepítése nem szükséges.

Ne felejtsük el, hogy a Tomcat szerver "tomcat6" user nevében fog futni! Mivel a Shibboleth servletnek szüksége van arra, hogy hozzáférjen a filerendszerhez, a Java Security Manager-t ki kell kapcsolni a   fájlban: TOMCAT6_SECURITY=no

Ahhoz, hogy a Tomcat számára üzembiztosan elegendő memóriát biztosítsunk, ugyanebbe a fájlba  adjuk meg: JAVA_OPTS="-Xms256M -Xmx512M -XX:-DisableExplicitGC "

Beállítás
A  fájlt kell szerkesztenünk

Ha a Tomcat Apache mögött fut
A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a  értéke "false" legyen, ezen kívül a hozzáférést korlátozhatjuk a localhost-ra is (hiszen a Connector-t csak a helyben futó Apache mod_proxy_ajp konnektora érheti el).

Ha a Tomcat önállóan, Apache nélkül fut
Ha a Tomcat Apache nélkül fut, akkor be kell állítani, hogy az SP-vel való kommunikációra fenntartott 8443-as porton egyből a Tomcat figyeljen. Ahol az  az IdP alapkönyvtára, a   pedig az IdP telepítésekor megadandó jelszó lesz.

További információ angolul

Apache beállítás
Tanúsítványok beszerzése és bemásolása  vonatkozó alkönyvtárai alá.

Meg kell adni, hogy az Apache figylejen a 443-as és 8443-as portokon. Az alábbiak kerüljenek a  fájlba Listen 443 Listen 8443

SSO URL (443-as port)
Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk. Ezen a porton valamilyen széles körben ismert tanúsítványt kell használni, mivel a felhasználók böngészőjének ismerniük kell(ene) a kibocsátót.

AA ill. Artifact (8443-as port)
Ezen keresztül az SP és az IdP közvetlenül kommunikálnak egymással. Ide arra a tanúsítványra van szükség, amely a föderációs metadatában szerepel - az aláírója nem érdekes.

A csatorna felépítésekor az IdP és az SP is autentikálja magát. Az SP autentikációját az Apache végzi, ami nem végez kibocsátó-ellenőrzést. Ez utóbbit az IdP alkalmazás végzi el, ezért nagyon fontos, hogy a kliens tanúsítványát az Apache továbbadja az alkalmazásnak.

A virtuális hoszt engedélyezése után be kell tölteni az  és   modulokat, majd újra kell indítani az apache-ot.

Letöltés
A hivatalos IdP kiadás innen innen tölthető le

Alternatívaként az NIIF által patchelt, ezáltal SLO képes IdP kiadást ajánljuk, ami a NIIF AAI oldalról érhető el. A Single Logout-képes IdP-ről további információ itt.

Kicsomagolás
A  fájl tartalma kicsomagolás után a   könyvtár alákerül cd /usr/local jar -xf shibboleth-idp-2.x.x-bin.zip

Endorsed jar állományok
Sajnos - legalábbis a cikk írásakor - a "kincstári" Sun-os Tomcat (Java?) JAXP parser egy ismert memóriaszivárgást tartalmaz, ezért a disztribúcióban az  könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat   könyvtárába.
 * A Debian alatti tomcat6 csomag használatakor a  könyvtárba kell tenni a jar file-okat (ezt a könyvtárt létre is kell hozni).

mkdir /usr/share/tomcat6/endorsed cp endorsed/*.jar /usr/share/tomcat6/endorsed/

Installer
export JAVA_HOME=/usr/jdk cd /usr/local/shibboleth-idp chmod 755 install.sh ./install.sh A telepítés során az alábbi kérdésekre kell választ adnunk:

Is this a new installation? Answering yes will overwrite your current configurat ion. [yes|no] yes

Új telepítés, vagy sem.

Where should the Shibboleth Identity Provider software be installed? [default: / opt/shibboleth-idp-2.0.0] /usr/local/shobboleth-idp

Itt található a letöltött és kicsomagolt shibboleth programcsomag

What is the hostname of the Shibboleth Identity Provider server? [default: idp.example.org] idp.example.org

Shibboleth IdP alkalmazás URI alapú azonosítója.

A keystore is about to be generated for you. Please enter a password that will be used to protect it. changeme

Feljegyzendő jelszó :)

Befejezés
Környezeti változó beállítása IDP_HOME=/usr/local/shibboleth-idp export IDP_HOME

Szimbolikus linkek megadása - az egyértelműség és konvenció kedvéért... mv $IDP_HOME/conf /etc/`basename $IDP_HOME` ln -s /etc/`basename $IDP_HOME` $IDP_HOME/conf mv $IDP_HOME/logs /var/log/`basename $IDP_HOME` ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs mkdir /var/lib/`basename $IDP_HOME` mv $IDP_HOME/metadata /var/lib/`basename $IDP_HOME`/metadata ln -s /var/lib/`basename $IDP_HOME`/metadata $IDP_HOME/metadata

Jogosultságok beállítása - hogy a  felhasználó hozzáférhessen az alábbi könyvtárakhoz chown -R tomcat6 /var/log/`basename $IDP_HOME` /var/lib/`basename $IDP_HOME`

További, már telepített IdP-től függő tomcat beállítás cd /var/lib/tomcat6/ mkdir -p conf/Catalina/localhost

Az így létrehozott könyvtárban készítsünk egy  nevű (a név legyen azonos a idp webalkalmazás nevével) fájlt az alábbi tartalommal:

Naplófájlok rotálása
Az alapértelmezett logging.xml nem törli a régi állományokat, ezért ezek egy idő után megtöltik a diszket.

Erre a korrekt megoldás az (lenne), ha a Logback alrendszert utasítjuk, hogy az N (a példában 90) napnál régebbi fájlokat rotálja ki. Ehhez a -ben adjuk meg a   paramétert az összes  y-nál, valahogy így:

Sajnos azonban jelenleg a logback csak egy állományt töröl, a régi file-okat megtartja (pl. akkor is, ha több, mint egy napig nem futott az IdP. Amíg ez nincs megoldva, addig kerülő megoldás lehet cron-ból törölni a régi file-okat sudo crontab -u tomcat6 -e MAILTO=mail@example.com 52 18 *  *   *     find /var/log/shibboleth-idp/ -mtime +90 -delete
 * 1) m h dom mon dow   command

Teszt
Ahhoz, hogy kiderítsük, működik-e (ill. fut-e :) ) az IdP webalkalmazásunk, ahhoz böngészőben hívjuk meg az alábbi urlt:, amennyiben az oldalon egy  -t látunk, akkor az alkalmazásunk fut, és elkezdhetjük beállítani az  attribútumok feloldását és  kiadását.

Ha nem működik a webalkalmazás, akkor az alábbi naplófájlokban kezdjünk el keresgélni:

A naplózás mélységét a  fájlban állíthatjuk be. Hibakereséshez érdemes a  értékét  -ra állítani.

Metadata aláírás ellenőrzés beállítása
Az IdP-be beállított metaadat(ok) valódiságának ellenőrzéséhez szükséges egy ún. beállítása. Ezt a  -ben kell megtenni a   részben:

  /path/to/idp/credentials/href-metadata-signer-2011.crt  

A konfigurációban hivatkozott  elérhető innen: https://metadata.eduid.hu/href-metadata-signer-2011.crt, SHA-1 lenyomata a következő:

HREF föderációs metadata beállítása az IdP-ben
A HREF metadata állomány elérhetősége:
 * http://metadata.eduid.hu/current/href.xml

A Shibboleth IdP  konfigurációban a következőképpen lehet beállítani a HREF metaadatot (fontos hogy az előző pontban leírt   is be legyen állítva):

  

Tovább a föderációba
Amennyiben a telepítendő IdP-t szeretnénk a HREF-be integrálni, úgy ennél a pontnál küldjünk egy levelet az [mailto:aai@niif.hu aai@niif.hu] címre, amely nyomán, ha minden rendben van, az IdP regisztrálásra kerül a Resource_Registry-ben, s a válasz e-mail tartalmaz majd két hivatkozást, melyekről letölthetők az  és   fájlok. Ezek már testreszabva tartalmazzák az IdP igényeit, az első fájlt elég csak bemásolni, a másodikban pedig - értelemszerűen - az egyes, a helyi erőforrásokra vonatkozó felhasználóineveket és jelszavakat kell kicserélni a megfelelőre.

További információk a Resource Registry-be történő felvételről

A Resource Registry automatikusan generálja minden egyes föderációban szereplő IdP számára a saját, testre szabott attribútum filterét, így célszerű úgy beállítani az IdP-t, hogy ezt a fájlt automatikusan töltse le. Ehhez hozzunk létre egy  nevű könyvtárat, adjunk rá írásjogot a   felhasználónak, majd szerkesszük a  fájlt. Az XML felső harmadában kerül megadásra az, melyet az alábbiak alapján kell átírni.
 * Attribútum filter automatikus frissítése

  

Hasznos lehet, ha a föderációs szűrőkön kívül további irányokba kívánunk IdP-nkből attribútumokat kiadni. Elterjedt, hogy pl. különböző google szolgáltatásokhoz lehet az intézményen keresztül autentikálni, amely beállítási részleteket értelemszerűen a Resource Registry nem tartalmazza, így a letöltött friss, és a régi, helyi adatokat is tartalmazó fájlok egyesítése bosszantó plusz munka lehet. Ezt elkerülendd dolgozhatunk több attribútum filterfájlból. Ehhez ismét a  fájlt kell szerkeszteni. Alább a fenti kódrészlet kiegészítése.
 * Több attribútum filter használata

<Service id="shibboleth.AttributeFilterEngine" xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine" configurationResourcePollingFrequency="3600000" configurationResourcePollingRetryAttempts="128"> <ConfigurationResource url="https://rr.aai.niif.hu/gen_attribute-filter.php/href/IDP_NEVE_AZ_RRBEN/attribute-filter.xml" file="/path/to/shibboleth-idp/confcache/attribute-filter.xml" xsi:type="resource:FileBackedHttpResource" /> <ConfigurationResource file="/path/to/shibboleth-idp/conf/attribute-filter-local.xml" xsi:type="resource:FilesystemResource" /> </Service>

Ezek a lépések természetesen kihagyhatók, ha nincs szándékunkban a föderáció tagjaivá válni, ekkor érdemes az alább részletezett attribútumokhoz kapcsolódó tudnivalókkal folytatni.


 * Statisztika küldés