„Shib2IdpInstall” változatai közötti eltérés

Innen: KIFÜ Wiki
(Tomcat önállóan, Apache nélkül fut)
(maxrefreshdelay HREF föderációs metadata beállítása az IdP-ben)
 
(46 közbenső módosítás, amit 4 másik szerkesztő végzett, nincs mutatva)
1. sor: 1. sor:
 
== Előkészületek ==
 
== Előkészületek ==
 
=== entityID ===
 
=== entityID ===
Fontos, hogy az entityID '''egyedi''' és '''állandó''' legyen. Javasolt forma: '''<code>https://idp.serverneve.hu/idp/shibboleth</code>'''.
+
Fontos, hogy az entityID '''egyedi''' és '''állandó''' legyen. Javasolt forma: '''<code>https://idp.intezmenyneve.hu/idp/shibboleth</code>'''.
  
 
=== Tűzfal ===
 
=== Tűzfal ===
7. sor: 7. sor:
  
 
== JDK ==
 
== JDK ==
Sajnos Etch alatt a <code>sun-java6-jdk</code> csomag függ egy csomó X-es csomagtól, melyeket nem biztos, hogy szeretnénk telepíteni egy szerveren, érdemes lehet
+
Debian Lenny alatt a <code>sun-java6-jdk</code> 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.
* feltenni a <code>sun-java6-jre</code> csomagot ÉS
 
* kézzel telepíteni egy JDK-t, mondjuk a http://java.sun.com oldalról letöltve
 
  
Ez igazából egy nagy ''hack'', ugyanis ahhoz, hogy a tomcat-et csomagból telepíteni tudjuk, kell a <code>java2-runtime</code> csomag, amelyet biztosít a JRE is, '''viszont''' a Tomcat-nek JDK kell, hogy JSP-t tudjon futtatni.
+
aptitude install sun-java6-jdk
:: <small>'''Megj.:''' Minden JSP-t első futtatáskor a konténer (Tomcat) lefordít Java kóddá, aztán byte-kóddá, ezért tart jó sokáig az - újraindítás utáni - első request. Ezután az eredményt elcache-eli, így csak akkor kell újrafordítania, ha a JSP megváltozik.</small>
 
 
 
A JDK telepítés elég egyszerű, letöltjük a java.sun.com oldalról a nekünk tetsző verziót, aztán kicsomagoljuk, mondjuk a <code>/usr/lib</code> alá, aztán csinálunk egy szimbolikus linket, hogy a <code>/usr/jdk</code> mindig a "jó" JDK-ra mutasson.
 
  
 
Állítsuk be, a <code>JAVA_HOME</code> környezeti változót!
 
Állítsuk be, a <code>JAVA_HOME</code> környezeti változót!
  export JAVA_HOME=/usr/jdk
+
  export JAVA_HOME=/usr/lib/jvm/java-6-sun
  
{{UNCERTAIN| Ez nem biztos, hogy kell (security provider, bouncy castle) }}
+
{{ATTENTION|Az <code>openjdk-6-jdk</code> csomag használata esetén ne felejtsük feltenni a <code>ca-certificates-java</code> csomagot, anélkül ugyanis hibát fogunk kapni az IdP indításakor!}}
  
 +
=== Shibboleth security provider ===
 +
{{INFO|A Shibboleth Security Provider csak akkor szükséges, ha a Java alkalmazásszerver (Tomcat) önállóan fog kéréseket feldolgozni és nem kerül elé proxy (Apache)}}
  
=== Shibboleth security provider ===
 
 
Be kell másolni a <code>lib/shib-jce-1.0.jar</code> állományt a <code>$JAVA_HOME/jre/lib/ext</code> könyvtárba. Ha  az <code>ext/</code> könyvtár nem létezik, akkor hozzuk létre.
 
Be kell másolni a <code>lib/shib-jce-1.0.jar</code> állományt a <code>$JAVA_HOME/jre/lib/ext</code> könyvtárba. Ha  az <code>ext/</code> könyvtár nem létezik, akkor hozzuk létre.
 
  cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext
 
  cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext
29. sor: 25. sor:
 
  security.provider.<b>7</b>=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
 
  security.provider.<b>7</b>=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
 
: '''Megj.:''' a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!
 
: '''Megj.:''' a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!
 +
 
=== Bouncy Castle JCE ===
 
=== Bouncy Castle JCE ===
 +
{{UNCERTAIN|Az alábbi leírás az 5-ös JVM-hez készült, 6-os JVM esetén erre nem biztos hogy szükség van.}}
 +
 
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.
 
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.
  
42. sor: 41. sor:
  
 
== Tomcat 6 ==
 
== 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 [[Tomcat55_to_Tomcat6|oldal szolgál]].
  
 
=== Telepítés ===
 
=== Telepítés ===
Ha minden rendben meg, akkor elegendő egy  
+
Ha minden rendben meg, és a squeeze source beállításra került, akkor elegendő egy  
  apt-get install tomcat6
+
  aptitude install tomcat6
Ez felpakolja a tomcat különböző függőségeit is, ám nem biztos, hogy a debian stabil kiadásában már szerepel.  
+
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.
 
 
Ahhoz, hogy a Tomcat rendben elinduljon, szükséges neki megmondani, hogy hol találja a JDK-t. Ezért tegyük a <code>/etc/default/tomcat6</code> fájlba a következőt:
 
JAVA_HOME=/usr/jdk
 
  
 
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 <code>/etc/default/tomcat6</code> fájlban:
 
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 <code>/etc/default/tomcat6</code> fájlban:
61. sor: 60. sor:
 
A <code>/etc/tomcat6/server.xml</code> fájlt kell szerkesztenünk
 
A <code>/etc/tomcat6/server.xml</code> fájlt kell szerkesztenünk
  
==== Tomcat Apache mögött fut ====
+
==== Ha a Tomcat Apache mögött fut ====
 
A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a <code>tomcatAuthentication</code> é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).
 
A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a <code>tomcatAuthentication</code> é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).
 
<source lang="xml">
 
<source lang="xml">
68. sor: 67. sor:
 
</source>
 
</source>
  
==== Tomcat önállóan, Apache nélkül fut ====
+
==== 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.
 
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.
 
<source lang="xml">
 
<source lang="xml">
87. sor: 86. sor:
 
Ahol az <code>IDP_HOME</code> az IdP alapkönyvtára, a <code>PASSWORD</code> pedig az [[#Shibboleth 2.0 IdP telepítés|IdP telepítésekor]] megadandó jelszó lesz.
 
Ahol az <code>IDP_HOME</code> az IdP alapkönyvtára, a <code>PASSWORD</code> pedig az [[#Shibboleth 2.0 IdP telepítés|IdP telepítésekor]] megadandó jelszó lesz.
  
{{INFO_EN|Amennyiben a Tomcat önállóan fut, szükség van a Shibboleth Security Provider telepítésére!}}
+
{{INFO|Amennyiben a Tomcat önállóan fut, szükség van a Shibboleth Security Provider telepítésére!}}
  
[https://spaces.internet2.edu/display/SHIB2/IdPApacheTomcatPrepare További információ angolul]
+
[https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare További információ angolul]
  
 
== Apache beállítás ==
 
== Apache beállítás ==
  
Tanusítványok beszerzése és bemásolása <code>/etc/ssl</code> vonatkozó alkönyvtárai alá.
+
Tanúsítványok beszerzése és bemásolása <code>/etc/ssl</code> 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 <code>/etc/apache2/ports.conf</code> fájlba
+
Meg kell adni, hogy az Apache figylejen a 443-as és 8443-as portokon. Az alábbiak kerüljenek a <code>/etc/apache2/ports.conf</code> fájlba
 
   
 
   
 
  Listen 443  
 
  Listen 443  
 
  Listen 8443
 
  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.
 
Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk.
 
+
<source lang="apache">
  <VirtualHost _default_:443>  
+
<VirtualHost _default_:443>  
   ServerName aai-logon.example.org  
+
   ServerName aai.example.org:443
 
   SSLEngine On  
 
   SSLEngine On  
  SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
+
   SSLCertificateFile /etc/ssl/certs/aai.example.org.crt  
   SSLCertificateFile /etc/ssl/certs/aai-logon.example.org.crt  
+
   SSLCertificateKeyFile /etc/ssl/private/aai.example.org.key  
   SSLCertificateKeyFile /etc/ssl/private/aai-logon.example.org.key  
+
   SSLCertificateChainFile /etc/ssl/certs/aai.example.org.crt  
   SSLCertificateChainFile /etc/ssl/certs/aai-logon.example.org.crt  
+
  ProxyRequests Off  
  ProxyRequests Off  
+
  <Proxy ajp://localhost:8009>   
  <Proxy ajp://localhost:8009>   
+
    Allow from all  
  Allow from all  
+
  </Proxy>   
  </Proxy>   
+
  ProxyPass /idp ajp://localhost:8009/idp retry=5  
  ProxyPass /idp ajp://localhost:8009/idp retry=5  
+
</VirtualHost>  
  </VirtualHost>  
+
</source>
 +
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.
  
Majd a 8443-as portot is beállítjuk
+
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 (<code>optional_no_ca</code>). 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 (<code>ExportCertData</code>).
'''Megjegyzés''': a 8443-as port beállítása csak akkor kell, ha Artifactot szeretnénk használni. Ha megelégszünk a HTTP-Post kínálta lehetőségekkel, akkor elég a 443-as portot beállítani.
+
{{ATTENTION_EN|Az Apache a tanúsítvány-ellenőrzésnél ellenőrzi a tanúsítvány típusát. Ezért az SP tanúsítványának vagy kliens tanúsítványnak kell lennie, vagy nem lehet benne típus információ.}}
 
+
<source lang="apache">
  <VirtualHost _default_:8443>
+
<VirtualHost _default_:8443>
   ServerName aai-logon.example.org  
+
   ServerName aai.example.org:8443
 
   SSLEngine On  
 
   SSLEngine On  
   SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
+
   SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
 
   SSLCertificateFile /etc/ssl/certs/aai-aa.example.org.crt  
 
   SSLCertificateFile /etc/ssl/certs/aai-aa.example.org.crt  
 
   SSLCertificateKeyFile /etc/ssl/private/aai-aa.example.org.key  
 
   SSLCertificateKeyFile /etc/ssl/private/aai-aa.example.org.key  
  SSLCertificateChainFile /etc/ssl/certs/aai-aa.example.org.crt
 
  SSLCACertificateFile /etc/ssl/ca-bundle.switchaai.crt
 
 
   SSLVerifyDepth 10  
 
   SSLVerifyDepth 10  
 
   SSLVerifyClient optional_no_ca  
 
   SSLVerifyClient optional_no_ca  
133. sor: 134. sor:
 
   ProxyRequests Off
 
   ProxyRequests Off
 
   <Proxy ajp://localhost:8009>
 
   <Proxy ajp://localhost:8009>
    Allow from all  
+
    Allow from all  
 
   </Proxy>
 
   </Proxy>
 
   ProxyPass /idp ajp://localhost:8009/idp retry=5  
 
   ProxyPass /idp ajp://localhost:8009/idp retry=5  
  </VirtualHost>  
+
</VirtualHost>  
 
+
</source>
 
 
Ezek után engedélyezni kell a virtuális hosztokat
 
 
 
a2ensite aai-logon
 
a2ensite aai-aa
 
apache2ctl -t
 
<font color="#999999">Syntax OK</font>
 
 
 
Majd az ssl modult
 
  
a2enmod ssl
+
A virtuális hoszt engedélyezése után be kell tölteni az <code>ssl</code> és <code>proxy_ajp</code> modulokat, majd újra kell indítani az apache-ot.
<font color="#999999">Module ssl installed; run /etc/init.d/apache2 force-reload to enable.</font>
 
 
 
Végül a proxy_ajp modult
 
 
 
a2enmod proxy_ajp
 
<font color="#999999">Enabling proxy as a dependency Module proxy installed; run /etc/init.d/apache2 force-reload to enable.
 
Module proxy_ajp installed; run /etc/init.d/apache2 force-reload to enable. </font>
 
 
 
Végezetül újra kell indítani az apache-ot
 
 
 
apache2ctl -k restart
 
  
 
== Shibboleth 2.x IdP servlet telepítés ==
 
== Shibboleth 2.x IdP servlet telepítés ==
165. sor: 146. sor:
 
====Letöltés====
 
====Letöltés====
  
A hivatalos IdP kiadás innen [http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/|innen tölthető le]
+
A hivatalos IdP kiadás innen [http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/ innen tölthető le]
  
Alternatívaként az NIIF által patchelt, ezáltal SLO képes [https://www.aai.niif.hu/sites/aai.niif.hu/files/shibboleth-identityprovider-2.1.3-slo3-bin.tar_.gz|IdP letöltése innen] (ajánljuk :) ) További [[Single_Logout_in_Shibboleth_IdP|információ itt]].
+
Alternatívaként az NIIF által patchelt, ezáltal SLO képes IdP kiadást ajánljuk, ami a [http://software.niif.hu NIIF AAI oldalról] érhető el. A Single Logout-képes IdP-ről további [[Single_Logout_in_Shibboleth_IdP|információ itt]].
  
 
====Kicsomagolás====
 
====Kicsomagolás====
178. sor: 159. sor:
 
==== Endorsed jar állományok ====
 
==== 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 <code>endorsed/</code> könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat <code>endorsed/</code> könyvtárába.
 
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 <code>endorsed/</code> könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat <code>endorsed/</code> könyvtárába.
: <small>A Debian alatti tomcat6 csomag használatakor a <code>/usr/share/tomcat6/common/endorsed </code> könyvtárba kell tenni a jar file-okat.</small>
+
: <small>A Debian alatti tomcat6 csomag használatakor a <code>/usr/share/tomcat6/common/endorsed </code> könyvtárba kell tenni a jar file-okat (ezt a könyvtárt létre is kell hozni).</small>
rm /usr/share/tomcat6/endorsed/xercesImpl.jar
 
rm /usr/share/tomcat6/endorsed/xml-apis
 
  
 +
mkdir /usr/share/tomcat6/endorsed
 
  cp endorsed/*.jar /usr/share/tomcat6/endorsed/
 
  cp endorsed/*.jar /usr/share/tomcat6/endorsed/
  
187. sor: 167. sor:
 
  export JAVA_HOME=/usr/jdk
 
  export JAVA_HOME=/usr/jdk
 
  cd /usr/local/shibboleth-idp
 
  cd /usr/local/shibboleth-idp
  chmod 755 ant.sh  
+
  chmod 755 install.sh  
  ./ant.sh
+
  ./install.sh
 
A telepítés során az alábbi kérdésekre kell választ adnunk:
 
A telepítés során az alábbi kérdésekre kell választ adnunk:
  
221. sor: 201. sor:
 
  mv $IDP_HOME/logs /var/log/`basename $IDP_HOME`
 
  mv $IDP_HOME/logs /var/log/`basename $IDP_HOME`
 
  ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs
 
  ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs
  mkdir /var/run/`basename $IDP_HOME`
+
  mkdir /var/lib/`basename $IDP_HOME`
  mv $IDP_HOME/metadata /var/run/`basename $IDP_HOME`/metadata
+
  mv $IDP_HOME/metadata /var/lib/`basename $IDP_HOME`/metadata
  ln -s /var/run/`basename $IDP_HOME`/metadata $IDP_HOME/metadata
+
  ln -s /var/lib/`basename $IDP_HOME`/metadata $IDP_HOME/metadata
  
 
'''Jogosultságok beállítása''' - hogy a <code>tomcat6</code> felhasználó hozzáférhessen az alábbi könyvtárakhoz
 
'''Jogosultságok beállítása''' - hogy a <code>tomcat6</code> felhasználó hozzáférhessen az alábbi könyvtárakhoz
  chown -R tomcatt6 /var/log/`basename $IDP_HOME` /var/run/`basename $IDP_HOME`  
+
  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''' (mi ez magyarul???)
+
'''További, már telepített IdP-től függő tomcat beállítás'''
 
  cd /var/lib/tomcat6/
 
  cd /var/lib/tomcat6/
 
  mkdir -p conf/Catalina/localhost
 
  mkdir -p conf/Catalina/localhost
242. sor: 222. sor:
 
         unpackWAR="false" />
 
         unpackWAR="false" />
 
</source>
 
</source>
 +
 +
==== 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 <code>logging.xml</code>-ben adjuk meg a <code>maxHistory</code> paramétert az ''összes'' <code>rollingPolic</code>y-nál, valahogy így:
 +
<source lang="xml">
 +
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
 +
  <FileNamePattern>/usr/local/shibboleth-idp/logs/idp-access-%d{yyyy-MM-dd}.log</FileNamePattern>
 +
  <maxHistory>4</maxHistory>
 +
</rollingPolicy>
 +
</source>
 +
 +
 +
Sajnos azonban jelenleg a logback [http://jira.qos.ch/browse/LBCORE-147 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
 +
#m h  dom mon dow  command
 +
52 18 *  *  *    find /var/log/shibboleth-idp/ -mtime +90 -delete
  
 
== Teszt ==
 
== Teszt ==
256. sor: 255. sor:
 
== Shibboleth 2.0 IdP beállítás ==
 
== Shibboleth 2.0 IdP beállítás ==
  
=== Metadaták beállítása ===
+
=== Metadata beállítása ===
{{ambox
+
==== Metadata aláírás ellenőrzés beállítása ====
| type = todo
+
Az IdP-be beállított metaadat(ok) valódiságának ellenőrzéséhez szükséges egy ún. <code>TrustEngine</code> beállítása. Ezt a <code>relying-party.xml</code> -ben kell megtenni a <code>Security Configurations</code> részben:
| image = [[Image:UnderConstruction.png|40px]]
+
 
| text = <big>'''A metadatákkal kapcsolatos rész még hiányzik'''</big>
+
<security:TrustEngine
----
+
    id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
{{#if:{{{1|}}} | {{{1}}} | Ha ki tudod egészíteni, megköszönjük!
+
  <security:Credential id="HREFSigner" xsi:type="security:X509Filesystem">
}}
+
  <security:Certificate>/path/to/idp/credentials/href-metadata-signer-2011.crt</security:Certificate>
}}
+
  </security:Credential>
 +
</security:TrustEngine>
 +
 
 +
A konfigurációban hivatkozott <code>href-metadata-signer-2011.crt</code> elérhető innen: https://metadata.eduid.hu/href-metadata-signer-2011.crt, SHA-1 lenyomata a következő: <code>FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66</code>
 +
 
 +
==== 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 <code>relying-party.xml</code> konfigurációban a következőképpen lehet beállítani a HREF metaadatot (fontos hogy az előző pontban leírt <code>TrustEngine</code> is be legyen állítva):
 +
 
 +
<MetadataProvider id="HREF-Metadata" 
 +
      xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
 +
      metadataURL="http://metadata.eduid.hu/current/href.xml"
 +
      backingFile="/path/to/idp/metadata/href.xml"
 +
      maxRefreshDelay="PT1H">
 +
  <MetadataFilter xsi:type="SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" />
 +
</MetadataProvider>
 +
 
 +
====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 <code>attribute-filter.xml</code> és <code>attribute-resolver.xml</code> 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.
 +
 
 +
[[Resource_Registry#IdP_regisztr.C3.A1ci.C3.B3|További információk a Resource Registry-be történő felvételről]]
 +
 
 +
;Attribútum filter automatikus frissítése
 +
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 <code>confcache</code> nevű könyvtárat, adjunk rá írásjogot a <code>tomcat6</code> felhasználónak, majd szerkesszük a <code>conf/service.xml</code>fájlt. Az XML felső harmadában kerül megadásra az <code>AttributeFilterEngine</code>, melyet az alábbiak alapján kell átírni.
 +
 
 +
<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" />
 +
</Service>
 +
 
 +
;Több attribútum filter használata
 +
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 <code>conf/service.xml</code> fájlt kell szerkeszteni. Alább a fenti kódrészlet kiegészítése.
 +
 
 +
<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.
 +
 
 +
;[[EduidFedStats|Statisztika küldés]]
  
 
=== [[Shib2IdpAuth | Autentikáció beállítása]] ===
 
=== [[Shib2IdpAuth | Autentikáció beállítása]] ===

A lap jelenlegi, 2013. március 14., 10:09-kori változata

Előkészületek

entityID

Fontos, hogy az entityID egyedi és állandó legyen. Javasolt forma: https://idp.intezmenyneve.hu/idp/shibboleth.

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 sun-java6-jdk 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 JAVA_HOME környezeti változót!

export JAVA_HOME=/usr/lib/jvm/java-6-sun


Shibboleth security provider


Be kell másolni a lib/shib-jce-1.0.jar állományt a $JAVA_HOME/jre/lib/ext könyvtárba. Ha az ext/ 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 $JAVA_HOME/jre/lib/security/java.security 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 bcprov-jdk-VERZIO.jar.) Letöltés után a .jar fájlokat a $JAVA_HOME/jre/lib/ext 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 $JAVA_HOME/jre/lib/security/java.security 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 /etc/default/tomcat6 fájlban:

TOMCAT6_SECURITY=no

Ahhoz, hogy a Tomcat számára üzembiztosan elegendő memóriát biztosítsunk, ugyanebbe a fájlba ( /etc/default/tomcat6 ) adjuk meg:

JAVA_OPTS="-Xms256M -Xmx512M -XX:-DisableExplicitGC "

Beállítás

A /etc/tomcat6/server.xml 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 tomcatAuthentication é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).

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

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.

<Connector port="8443"
           maxHttpHeaderSize="8192"
           maxSpareThreads="75"
           scheme="https"
           secure="true"
           clientAuth="want"
           SSLEnabled="true"
           sslProtocol="TLS"
           keystoreFile="IDP_HOME/credentials/idp.jks"
           keystorePass="PASSWORD"
           truststoreFile="IDP_HOME/credentials/idp.jks"
           truststorePass="PASSWORD"
           truststoreAlgorithm="DelegateToApplication"/>

Ahol az IDP_HOME az IdP alapkönyvtára, a PASSWORD 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 /etc/ssl 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 /etc/apache2/ports.conf 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.

 <VirtualHost _default_:443> 
   ServerName aai.example.org:443 
   SSLEngine On 
   SSLCertificateFile /etc/ssl/certs/aai.example.org.crt 
   SSLCertificateKeyFile /etc/ssl/private/aai.example.org.key 
   SSLCertificateChainFile /etc/ssl/certs/aai.example.org.crt 
   ProxyRequests Off 
   <Proxy ajp://localhost:8009>  
     Allow from all 
   </Proxy>  
   ProxyPass /idp ajp://localhost:8009/idp retry=5 
 </VirtualHost>

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 (optional_no_ca). 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 (ExportCertData).

Az Apache a tanúsítvány-ellenőrzésnél ellenőrzi a tanúsítvány típusát. Ezért az SP tanúsítványának vagy kliens tanúsítványnak kell lennie, vagy nem lehet benne típus információ.
 <VirtualHost _default_:8443>
   ServerName aai.example.org:8443 
   SSLEngine On 
   SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
   SSLCertificateFile /etc/ssl/certs/aai-aa.example.org.crt 
   SSLCertificateKeyFile /etc/ssl/private/aai-aa.example.org.key 
   SSLVerifyDepth 10 
   SSLVerifyClient optional_no_ca 
   SSLOptions -StdEnvVars +ExportCertData 
   ProxyRequests Off
   <Proxy ajp://localhost:8009>
     Allow from all 
   </Proxy>
   ProxyPass /idp ajp://localhost:8009/idp retry=5 
 </VirtualHost>

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

Shibboleth 2.x IdP servlet telepítés

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 shibboleth-idp-2.x.x-bin.zip fájl tartalma kicsomagolás után a /usr/local/shibboleth-idp 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 endorsed/ könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat endorsed/ könyvtárába.

A Debian alatti tomcat6 csomag használatakor a /usr/share/tomcat6/common/endorsed 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 tomcat6 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 idp.xml nevű (a név legyen azonos a idp webalkalmazás nevével) fájlt az alábbi tartalommal:

<Context 
        docBase="/usr/local/shibboleth-idp/war/idp.war" 
        privileged="true" 
        antiResourceLocking="false" 
        antiJARLocking="false" 
        unpackWAR="false" />

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 logging.xml-ben adjuk meg a maxHistory paramétert az összes rollingPolicy-nál, valahogy így:

 <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
   <FileNamePattern>/usr/local/shibboleth-idp/logs/idp-access-%d{yyyy-MM-dd}.log</FileNamePattern>
   <maxHistory>4</maxHistory>
 </rollingPolicy>


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
#m h  dom mon dow   command
52 18 *   *   *     find /var/log/shibboleth-idp/ -mtime +90 -delete

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: https://idp.example.org/idp/profile/Status, amennyiben az oldalon egy ok-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:

  • /var/log/shibboleth/idp-error.log
  • /var/log/shibboleth/idp-process.log

A naplózás mélységét a /etc/shibboleth/logging.xml fájlban állíthatjuk be. Hibakereséshez érdemes a <ErrorLog> értékét DEBUG-ra állítani.

Shibboleth 2.0 IdP beállítás

Metadata beállítása

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. TrustEngine beállítása. Ezt a relying-party.xml -ben kell megtenni a Security Configurations részben:

<security:TrustEngine 
   id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
 <security:Credential id="HREFSigner" xsi:type="security:X509Filesystem">
  <security:Certificate>/path/to/idp/credentials/href-metadata-signer-2011.crt</security:Certificate>
 </security:Credential>
</security:TrustEngine>

A konfigurációban hivatkozott href-metadata-signer-2011.crt elérhető innen: https://metadata.eduid.hu/href-metadata-signer-2011.crt, SHA-1 lenyomata a következő: FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66

HREF föderációs metadata beállítása az IdP-ben

A HREF metadata állomány elérhetősége:

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

<MetadataProvider id="HREF-Metadata"  
     xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
     metadataURL="http://metadata.eduid.hu/current/href.xml"
     backingFile="/path/to/idp/metadata/href.xml" 
     maxRefreshDelay="PT1H">
  <MetadataFilter xsi:type="SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" />
</MetadataProvider>

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 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 attribute-filter.xml és attribute-resolver.xml 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

Attribútum filter automatikus frissítése

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 confcache nevű könyvtárat, adjunk rá írásjogot a tomcat6 felhasználónak, majd szerkesszük a conf/service.xmlfájlt. Az XML felső harmadában kerül megadásra az AttributeFilterEngine, melyet az alábbiak alapján kell átírni.

<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" />
</Service>
Több attribútum filter használata

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 conf/service.xml fájlt kell szerkeszteni. Alább a fenti kódrészlet kiegészítése.

<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

Autentikáció beállítása

Attribútum feloldás beállítása

Attribútum kiadás beállítása