Kaikissa ohjeeseen liittyvissä asioissa ota yhteys haka@csc.fi.

Konfiguraatioesimerkit on tarkoitettu muutettavaksi oletustiedostojen vastaaviin kohtiin. Älä lisää esimerkkejä suoraan sellaisenaan asetustiedostoihin tai poista asetustiedostoista elementtejä.

Shibboleth Identity Provider -ohjelmiston versio 2.0 on yhteensopiva Shibboleth 1.3:n kanssa sekä uutena ominaisuutena se tukee SAML 2:ta. Shibboleth 1.3 ja SAML 2 eivät ole keskenään yhteensopivia, mutta Shibboleth 2 IdP -ohjelmistossa ne voivat olla samaan aikaan käytössä, jolloin molemmat protokollat ovat tuettuna samassa asennuksessa.

Suurimmat erot aiempaan Shibboleth 1.3 versioon koskevat SAML2 tukea, joka tuo uusia konfiguraatiovaihtoehtoja mukanaan. Shibboleth on SAML1.1:sta laajennettu protokolla, joka ei ole yhteensopiva muiden kuin toisten Shibboleth toteutusten kanssa. Hakassa on käytetty koko sen olemassaolon ajan Shibbolethia tiedonsiirtoon.

Pääosiltaan Shibboleth 2 on hyvin samankaltainen kuin aiempi versio 1.3. SAML2 tuen käyttöönotto ei vaadi erityisiä toimenpiteitä, oletusasetuksilla Shibboleth 2 asennus ottaa myös SAML2:n käyttöön. Käytettävä protokolla SP:n kanssa valitaan SP:n kyselyn ja IdP:n metadatan avulla.

SAML2 määrittelyt löytyvät OASIS:in sivuilta: http://www.oasis-open.org/specs/index.php#samlv2.0

Asennus ja käyttöönotto

Shibboleth IdP:n asennuksessa on useita seikkoja, jotka riippuvat käytettävästä ympäristöstä, jossa IdP:n tulee toimia. Yksiselitteisen dokumentaation tekeminen, joka toimisi kaikissa tapauksissa on mahdotonta. Kaikissa asennukseen liittyvissä kysymyksissä voi ottaa yhteyttä haka@csc.fi.

Ennen asennusta on hyvä tutustua Shibboleth ja SAML-protokollien toimintaan SWITCH:n demon avulla sekä selvittää missä sijaitsevat käyttäjätiedot. Lisäksi kaikissa asennusvaiheissa on syytä pitää silmällä Shibbolethin virallista wikiä, koska monet asiat voi tehdä usealla eri tavalla, joiden keskinäinen paremmuus on hyvä selvittää.

Shibboleth IdP:n perusasennuksen vaiheet, joilla saa perustoiminnallisuuden rakennettua. Kun perustoiminnallisuus on kunnossa, voi siirtyä Hakan vaatimusten täyttämiseen.

1. Alustan asennus (Java, Tomcat (Apache))

2. Shibbolethin asennus
3. Peruskonfiguraatio (IdP:n nimi, varmenteet jne.)
   
4. Käyttäjätunnistusmekanismin konfigurointi
   
5. Attribuuttien haku tietovarastoista ja luovutussäännöt
   
6. Metadatan käyttöönotto
7. Testaaminen jonkin Shibboleth SP:n kanssa (ilman SP:tä ei IdP:tä voi käyttää).
   

Alusta

Shibboleth IdP on Javalla toteutettu sovellus, joka vaatii Java-sovelluspalvelimen. Virallisesti tuetut alustat ovat Java 1.6 ja Jetty 7, Apache Tomcat 6.0 tai JBoss 4.2. Java sovelluspalvelimen edessä voi käyttää Apache WWW-palvelinta.

Sopiva lähtökohta asennukselle on kun Tomcatin jsp-examples -sovellukset toimivat https-yhteyden yli. Tomcatin edessä voi käyttää Apachea yhdessä mod_jk:n tai ajp-proxyn kanssa tai käyttää suoraan Tomcatin omaa www-palvelinta.

Yleensä Shibbolethin käyttäjälle näkyvä osio, jossa käyttäjät käyvät tunnistautumassa, asennetaan omaan virtualhost:iin https-porttiin 443. Loppukäyttäjien porttiin soveltuvat normaalit https-sivuston asetukset.

Asennus

Ladattu IdP-asennuspaketti shibboleth-idp-2.X.X-bin.zip puretaan:

unzip shibboleth-idp-2.X.X-bin.zip

Paketti purkautuessaan luo identityprovider-hakemiston, jossa on asennusskripit ant.sh. Tarvittaessa anna asennusskriptille suoritusoikeudet:

chmod +x ant.sh

Asennusskriptin suorittaminen käynnistää asennuksen, joka kyselee mm. mihin hakemistoon Shibboleth IdP asennetaan ja mistä löytyy käytettävä Tomcat. Ennen asennuksen käynnistämistä tulee käytettävällä käyttäjätunnuksella olla riittävät oikeudet luoda asennushakemisto sekä JAVA_HOME ympäristömuuttuja asetettuna.

Konfigurointi

IdP:n asetuksia hallitaan asennushakemiston conf-hakemistosta. Asetukset on hajautettu useaan eri tiedostoon, joista tärkeimmät ovat relying-party.xml, attribute-resolver.xml ja attribute-filter.xml.

Suurin osa muutoksista ei vaadi IdP:n uudelleenkäynnistämistä, mutta usein on varmuuden vuoksi suositeltavaa käynnistää IdP uudelleen ainakin asennuksen alkuvaiheen aikana.

IdP:n nimeäminen

IdP providerId eli nimi, jolla se tunnistetaan luottamusverkon palveluissa, joille IdP käyttäjätäietoja tarjoaa, annetaan relying-party.xml -tiedostossa. Nimen tulee olla uniikki eli esimerkiksi alla käytetyn mukainen palvelimen osoitteeseen perustuva on sopiva arvo. Arvo ilmoitetaan CSC:lle IdP-palvelimen rekisteröinnin yhteydessä.

Samassa osiossa on varmenteisiin liittyvä asetus, jolla määritetään mitä varmenteita käytetään.

<DefaultRelyingParty provider="https://aitta2.funet.fi/idp/shibboleth"
  defaultSigningCredentialRef="IdPCredential">

Varmenteet

Shibbolethin luottamussuhteet varmistetaan varmenteiden avulla. Niiden sijainti tiedostojärjestelmässä konfiguroidaan relying-party.xml -tiedostossa.

<security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
  <security:PrivateKey>/hakemisto/varmenne.key</security:PrivateKey>
  <security:Certificate>/hakemisto/varmenne.crt</security:Certificate>
</security:Credential>

Käyttäjätunnistus

Vaikka usein puhutaan Shibboleth-käyttäjätunnistuksesta, on itse käyttäjän tunnistaminen kuitenkin yleensä erillinen asia Shibbolethista. Varsinainen shibboleth-toiminta alkaa vasta kun käyttäjätunnistus on suoritettu.

Käyttäjätunnistus voidaan toteuttaa Shibbolethin kanssa useilla eri tavoilla. Versiosta 2 lähtien Shibboleth tarjoaa mahdollisuuden yksinkertaiseen käyttäjätunnus-salasana autentikointiin LDAP-hakemistoa vasten. Tällöin handler.xml -tiedostossa otetaan alla olevan esimerkin mukaisesti käyttöön, login.config -tiedostoon konfiguroidaan käytettävän LDAP-palvelimen tiedot.

<!--  Username/password login handler -->
<LoginHandler xsi:type="UsernamePassword" 
    jaasConfigurationLocation="file:///hakemisto/login.config">
  <AuthenticationMethod>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </AuthenticationMethod>
</LoginHandler>

Tälle vaihtoehtoinen tapa on käyttää autentikointimekanismia, joka täyttää REMOTE_USER -muuttujan. Tällöin tulee ottaa pois käytöstä Shibbolethin oma autentikointimekanismi. Soveltuvia RemoteUser-autentikaatioon ovat esim. Tomcatin oma FORM-autentikointi, Pubcookie tai CAS.  Apachen Basic Auth ei kuitenkaan ole soveltuva tuotantokäyttöiseen IdP:iin.

Muita kuin Shibbolethin omia autentikointimekanismeja käytettäessä sallitaan ne käyttöön alla olevan mukaisesti:

<!-- Remote User login handler -->
<LoginHandler xsi:type="RemoteUser">
  <AuthenticationMethod>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
   </AuthenticationMethod>
</LoginHandler>

Lisäksi käytettävällä autentikointimekanismilla tulee suojata IdP-palvelimen /Authn/RemoteUser sijanti. Tomcatin FORM-autentikoinnilla se tehdään idp-sovelluksen Tomcatin webapps-hakemiston alta löytyvässä web.xml -tiedostossa. Lisäksi vaaditaan Tomcatin server.xml -tiedostossa vaaditaan soveltuva realm ja halutuille rooleille annettava oikeudet autentikoitumiseen. Esimerkki on Tomcat 6:n mukainen. Lisätietoja löytyy Tomcatin omasta dokumentaatiosta.

<security-constraint>
  <display-name>Shibboleth IdP</display-name>
  <web-resource-collection>
    <web-resource-name>user authentication</web-resource-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
<auth-constraint> 
  <role-name>staff</role-name> 
</auth-constraint>
<user-data-constraint>
  <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

<login-config>
  <auth-method>FORM</auth-method>
  <realm-name>IdP Password Authentication</realm-name>
  <form-login-config>
    <form-login-page>/login.jsp</form-login-page>
    <form-error-page>/login-error.jsp</form-error-page>
  </form-login-config>
</login-config>

Samassa web.xml-tiedostossa on myös joitakin Shibboleth-määrityksiä, jotka tulee jättää sinne. Mikäli käyttää RemoteUser-autentikointia, voi toki Shibbolethin oman käyttäjätunnus/salasana-autentikoinnin ottaa pois käytöstä.

Tietosuojaseloste

...
<body>
  <img src="<%= request.getContextPath() %>/images/logo.jpg" />
  <h2>Shibboleth Identity Provider Login to Service Provider <%=entityDescriptor.getEntityID()%></h2>
  <!-- Muokkaus Tietosuojaselosteen linkille -->
  <%
    String strUrl2PrivacyPolicy;
    strUrl2PrivacyPolicy = "https://haka.funet.fi/privacypolicy/privacypolicy.php?providerID="; 
    strUrl2PrivacyPolicy += entityDescriptor.getEntityID();
  %> 
  <a href=<%=strUrl2PrivacyPolicy%>>Tietosuojaseloste</a> SP:lle<%=entityDescriptor.getEntityID()%>
  <!-- Muokkaus päättyy -->
  <p>
  Existing Session: <%= userSession != null %><br/>...	

Metadata

Kukin IdP tarvitsee tiedon palveluista, joihin IdP:n avulla voi kirjautua. Nämä palvelimet kuvataan metadatoissa, jotka Hakassa voi käydä noutamassa Haka-luottamusverkoston metatietosivulta.  Kunkin IdP:n tulee huolehtia että sillä on käytössään tuorein metadata, sekä käyttäjien palvelemiseksi sekä tietoturvan vuoksi.

Suositeltava tapa helpottamaan päivittämistä on asettaa IdP hakemaan metatieto suoraan verkosta, jolloin se päivittyy automaattisesti. Hakan operaattori CSC allekirjoittaa metadatan varmenteellaan, jotta Hakan palvelut voivat luottaa metadataan. CSC:n käyttämän varmenteen julkinen avain tulee tallentaa SP:lle, johon vertaamalla tarkistus tehdään.

Metadatan automaattinen päivitys konfiguroidaan relying-party.xml -tiedostosta. Esimerkissä tehdään varmuuskopio metadatasta mikäli uuttaa metadataan ei voida hakea. Lisäksi otetaan käyttöön allekirjoituksen tarkistus varmenteen avulla:

<MetadataProvider id="URLMD" xsi:type="FileBackedHTTPMetadataProvider" 
      xmlns="urn:mace:shibboleth:2.0:metadata"
      metadataURL="https://haka.funet.fi/fed/haka-metadata.xml" 
      backingFile="/hakemisto/haka_metadata_backup.xml">
  <MetadataFilter xsi:type="SignatureValidation" 
     trustEngineRef="shibboleth.MetadataTrustEngine" /> 
</MetadataProvider>

<security:TrustEngine id="shibboleth.MetadataTrustEngine" 
      xsi:type="security:StaticExplicitKeySignature">
  <security:Credential id="Haka_metadata_signing" xsi:type="security:X509Filesystem">
    <security:Certificate>/hakemisto/varmenne.crt</security:Certificate>
  </security:Credential>
</security:TrustEngine>

MetadataProvider-elementtejä voi olla useita, joista vaikka yksi verkosta haettava ja toinen paikallisella levyllä oleva. Täten voidaan yhtä IdP:ia käyttää Hakan ja omien sisäisten palveluiden kanssa samanaikaisesti.

Metadatan päivittäiminen ei edellytä IdP:n uudelleenkäynnistämistä. Uusi metadata tulee käyttöön lähes välittömästi paikalliselta levyltä luettaessa.

CSC:n testipalvelinten kanssa testattaessa, saa metadatan valmiina ohjeiden mukaisesti. Jos käyttää omaa testipalvelinta, voi tarvittavan metadatan tehdä itse käyttäen Shibbolethin mukana sekä Shibboleth Wikissä olevia tiedostoja pohjana.

Attribuutit

Hakassa käytettävät attribuutit on määritelty funetEduPerson-skeemassa. Skeema käsittelee millä tavalla attribuutit välitetään IdP:stä SP:iin, se ei siis ota kantaa siihen minkälaisia attribuutteja organisaatiossa käytetään tai missä/miten niitä tallennetaan. Olemassa olevaa tietovarastoa ei siis ole tarpeen muokata funetEduPerson-skeeman mukaiseksi, attribuutit voidaan IdP:ssä muokata ja nimetä uudelleen.

Käyttäjäattribuutit voidaan välittää palvelulle käyttäjän selaimen mukana (Attribute Push), jolloin ne salataan metadatassa olevan palvelun varmenteen avulla. Mikäli attribuutteja ei välitetä käyttäjän selaimessa ottavat palvelut yhteyden IdP:n AA-palveluun (Attribute Query), josta ne kysyvät attribuutteja käyttäjän selaimesta saamansa satunnaisluvun avulla. Tällöin ei tarvita varmenteita metadatassa, mutta IdP:ssä on oltava AA-palvelu. Shibboleth 1.3:ssa käytetään oletuksena Attribute Querya, SAML2:ssa Attribute Pushia.

Käyttäjäattribuutit haetaan jostain tietovarastosta kuten LDAP-hakemisto tai relaatiotietokanta. Joitakin attribuutteja voidaan myös muodostaa Shibbolethilla itsellään. Palveluille luovutetaan ne attribuutit, jotka kullekin palvelulle sallitaan IdP:n attribute-filter.xml -asetustiedostossa. Haka tarjoaa IdP-ylläpitäjille valmiin pohjan, jossa on kaikkien Haka-palveluiden tarvitsemat attribuuttien luovutussäännöt Haka-metadatan jakelusivulla. Tiedostoa ei voi Shibbolethin avulla määrittää automaattisesti päivittyväksi, vaan se tulee päivittää joko käsin tai esim. cron-skriptin avulla. Attribute-filter.xml tiedoston päivityksen jälkee tulee IdP käynnistää uudelleen ellei salli konfiguraatioiden latausta lennossa. Salliminen tehdään  https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigConfig ohjeiden mukaisesti lisäämällä tarkistuväli.

Uutena ominaisuutena Shibboleth 2:ssa voi attribuuttien luovutussääntötiedostoja olla useita. Voidaan siis tehdä oma sääntötiedosto, jossa ovat Hakaan liittyvien palveluiden säännöt ja toinen omille organisaation sisäisille palveluille. Attribuuttisääntötiedostot konfiguroidaan service.xml -tiedostossa seuraavasti. Attribuuttisääntötiedoston voi ladata myös verkossa sijaitsevasta osoitteesta.

<Service id="shibboleth.AttributeFilterEngine"
             xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine">
 <ConfigurationResource file="/hakemisto/shibboleth-idp/conf/attribute-filter.xml" 
   xsi:type="resource:FilesystemResource" />
 <ConfigurationResource file="/hakemisto/shibboleth-idp/conf/attribute-filter-local.xml" 
   xsi:type="resource:FilesystemResource" />
  <ConfigurationResource url="https://domain.fi/attribute-filter.xml" 
    file="/v/net/idp.csc.fi/idp/metadata/attribute-filter-kalmar.xml" 
    xsi:type="resource:FileBackedHttpResource" />
</Service>

Lisäksi jokaisessa attribuuttifiltterissä täytyy olla oma uniikki id:

<AttributeFilterPolicyGroup id="ShibbolethFilterPolicyTunniste"

Attribuuttien haku tietovarastosta konfiguroidaan attribute-resolver.xml tiedostossa. Attribuuttien hakua varten määritellään yksi tai useampi liityntä attribuuttilähteisiin (resolver:DataConnector), myös Shibbolethin itse tekemä attribuutti muodostaa lähteen. Attribuuttilähteinä voivat toimia esim. LDAP-hakemisto kuten alla tai relaatiotietokanta, josta esimerkki löytyy IdP asennuksen attribute-resolver.xml -tiedostosta.

<!-- Example LDAP Connector -->
<resolver:DataConnector id="ldapHakemisto" xsi:type="LDAPDirectory" 
    xmlns="urn:mace:shibboleth:2.0:resolver:dc"
    ldapURL="ldap://ldap.domain.com"
    baseDN="ou=users,dc=domain,dc=com" 
    principal="uid=ldapuser,ou=ldap_users,dc=domain,dc=com"
    principalCredential="password" 
    cacheResults="false"> 
  <FilterTemplate>
    <![CDATA[
      (uid=$requestContext.principalName)
    ]]>
  </FilterTemplate>
</resolver:DataConnector>

Kaikille käyttäjille saman attribuutin antaminen voidaan toteuttaa static-muotoisen attribuuttilähteen avulla. Esimerkissä annetaan kaikille käyttäjille sijaintitiedoksi (attribuutti l) Espoo.

<resolver:DataConnector id="staticAttributes" xsi:type="Static" 
    xmlns="urn:mace:shibboleth:2.0:resolver:dc">
  <Attribute id="l">
    <Value>Espoo</Value>
  </Attribute>
</resolver:DataConnector>

Lähteiden määrityksen lisäksi kullakin attribuutilla on tulee olla määrittely miten se enkoodataan ennen lähetystä. Mikäli attribuutille ei ole AttributeDefinition-määritystä, ei sitä käsitellä vaikka se löytyisi LDAP-hakemistosta.

Alla esimerkissä on sähköpostiosoite, joka saadaan hakemalla se LDAP-hakemistosta (ldapHakemisto-viittaus). Attribuutti l, saadaan muodostetusta staattisesta attribuuttilähteestä.

Viimeisenä muodostetaan käyttäjän eduPersonPrincipalName käyttäjätunnuksesta joka haetaan LDAP-hakemistosta ja IdP:n verkkotunnuksesta (scope) muodostaen username@domain.fi. Attribuutti enkoodataan inline-muotoisena Shibboleth 1.3 muodossa suurimman yhteensopivuuden vuoksi.

Jokaisella attribuutilla on id eli tunniste, jolla siihen viitataan Shibbolethin sisällä. Hakan metadatassa on käytetty id:nä attribuutin virallista nimeä, jonka alkuun on lisätty 'id-'. Shibbolethin suunnittelussa ei ole oletettu että attribuuttifiltteri tulee ulkopuoliselta taholta vaan se on IdP ylläpidon määritettävä. Tämän takia on Haka-metadatassa tehty arvio että id-alkuisia attribuuttitunnisteita voidaan käyttää kaikissa Haka IdP:ssä. Jos/kun siis haluat käyttää suoraan Hakan tarjoamaa attribute-filter.xml:ää, varmista, että IdP:si attribute-resolver.xml:ssa attribuuttien id:t täsmäävät attribute-filter.xml:n vastaaviin!

<resolver:AttributeDefinition id="id-urn:mace:dir:attribute-def:mail"
    xsi:type="Simple" 
    xmlns="urn:mace:shibboleth:2.0:resolver:ad"
    sourceAttributeID="mail">
  <resolver:Dependency ref="ldapHakemisto" />
  <resolver:AttributeEncoder xsi:type="SAML1String" 
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:mace:dir:attribute-def:mail" />
  <resolver:AttributeEncoder xsi:type="SAML2String" 
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
</resolver:AttributeDefinition>

<resolver:AttributeDefinition id="id-urn:mace:dir:attribute-def:l" 
    xsi:type="Simple" 
    xmlns="urn:mace:shibboleth:2.0:resolver:ad"
    sourceAttributeID="l">
  <resolver:Dependency ref="staticAttributes" />
  <resolver:AttributeEncoder xsi:type="SAML1String" 
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:mace:dir:attribute-def:l" />
  <resolver:AttributeEncoder xsi:type="SAML2String" 
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:oid:2.5.4.7" friendlyName="l" />
</resolver:AttributeDefinition>

<resolver:AttributeDefinition id="id-urn:mace:dir:attribute-def:eduPersonPrincipalName" 
    xsi:type="Scoped" 
    xmlns="urn:mace:shibboleth:2.0:resolver:ad"
    scope="domain.fi" sourceAttributeID="uid">
  <resolver:Dependency ref="ldapHakemisto" />
  <resolver:AttributeEncoder xsi:type="SAML1ScopedString" 
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    scopeType="inline" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />
  <resolver:AttributeEncoder xsi:type="SAML2ScopedString" 
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
</resolver:AttributeDefinition>

Esimerkki attribute-resolver.xml -tiedostoon on koottu funetEduPerson-skeeman mukaisia attribuutteja. HUOM. tiedostoa ei voi käyttää sellaisenaan, se tulee räätälöidä kutakin IdP:tä varten. Tarkat ohjeet tietokantoihin ja LDAP-hakemistoon kytkeytymistä varten löytyvät Shibboleth Wikistä sekä Shibbolethin mukana tulevasta attribute-resolver.xml -tiedostossa.

Valmiiden attribuuttien haun lisäksi voidaan Shibbolethissä luoda käyttäjälle attribuutteja eri tavoin:

• yhdistelemällä (esim. tehdään henkilön nimi yhdistämällä etu- ja sukunimi)
  

• muokkaamalla (esim. poistetaan epätoivottu merkkijono jostakin attribuutista säännöllisellä lausekkeella)
• annetaan kaikille käyttäjille sama attribuutti (esim. käyttäjän kotiorganisaatioattribuutiksi korkeakoulun domain)
• liittämällä uusia attribuutteja haettujen perusteella (esim. jos käyttäjän affiliation on student tai staff, lisätään aina member)
  

Usein onkin siis helpompaa muokata attribuutteja Shibbolethissa kuin ruveta muuttamaan tietovarastoja. Täydellinen lista eri tavoista muokata attribuutteja löytyy Shibboleth Wikistä.

Loki-tiedostot

Shibboleth IdP:n tekemiä loki-tiedostoja hallitaan logging.xml -tiedoston avulla. Tärkeimmät asetukset ovat muodostuvien lokien tarkkuus ja niiden sijainti.

Ongelmatilanteissa ainakin Shibboleth-lokin on oltava debug-tilassa, jotta tapahtumista saa luotettavan selvyyden. Normaalissa käytössä ei debug-tilaa kuitenkaan tule käyttää. Yleensä kiinnostavimpia ovat IdP-osion logit (alla ensimmäisenä), mutta alla myös esimerkkejä muista mahdollisesti tarvittavista.

<!--
  Loggers define indicate which packages/categories are logged, at which level, and to which appender.
  Levels: ALL, ERROR, WARN, INFO, DEBUG, TRACE, OFF
-->

<!-- Logs IdP, but not OpenSAML, messages -->
<logger name="edu.internet2.middleware.shibboleth">
  <level value="DEBUG" />
</logger>

<!-- Logs OpenSAML, but not IdP, messages -->
<logger name="org.opensaml">
  <level value="INFO" />
</logger>
    
<!-- Logs inbound and outbound protocols messages at DEBUG level -->
<logger name="PROTOCOL_MESSAGE">
  <level value="WARN" />
</logger>

<!-- LDAP -->
<logger name="edu.vt.middleware.ldap">
  <level value="INFO" />
</logger>

Tietosuojaseloste

Jotta lainsäädännön vaatimukset henkilötietojen siirrolle täyttyvät, tulee käyttäjälle tarjota mahdollisuus hyväksyä hänen tietojensa siirto palveluihin.