UKK

Liittyminen ja rekisteröinti

Asiakkaamme haluaisi Haka-kirjautumisen palveluun mahdollisimman nopeasti, mutta liittymisprosessi on kesken. Miten sitä voisi nopeuttaa?

Ohjausryhmä hyväksyy Haka-kumppanit ja tämän lisäksi palvelusopimuksen allekirjoituskierrossa CSC:llä kuluu aikaa. Tätä prosessia ei voi nopeuttaa, vaan projektissa siihen kannattaa varata kalenteriaikaa 4-6 viikkoa (yleensä sopimiskierto on kuitenkin valmis jo muutamassa viikossa). Liittymisprosessi on kuvattu omalla sivullaan.

Samanaikaisesti sopimusprosessin edetessä Haka-kirjautumisen käyttöönottoa voi edistää teknisesti toteuttamalla ja testaamalla palvelun Haka-integraatio valmiiksi. Kaikki Hakaan liitettävät entiteetit testataan vasten operaattorin testipalvelimia ennen tuotantometadataan lisäämistä. Operaattori varmistaa ennen tuotantometadataan siirtämistä, että on onnistuneesti toteutettu kirjautuminen vasten testipalvelinta. Entiteetin SAML-profiilinmukaisuus tarkistetaan pintapuolisesti.

Testaamisen lisäksi tarvitaan myös vahvistus kumppanin tai jäsenen hallinnolliselta yhteyshenkilöltä. Valmistele yhteyshenkilö jo etukäteen, että hän arvioi vastuulleen kuuluvat asiat ajoissa ennen tuotantoon siirtymistä:

Luottamusverkoston jäsenen tai kumppanin hallinnollinen yhteyshenkilö varmistaa erityisesti, että

• • palvelu ei ole ristiriidassa luottamusverkoston toiminnan tarkoituksen kanssa (Liite 2: ”Haka-luottamusverkoston toiminnan tarkoitus on tukea korkeakoulujen ja tutkimuslaitosten toimintaa”)
  • hakemuksessa esitetyt henkilötiedot, joita palvelu katsoo tarvitsevansa loppukyttäjistä, ovat palvelun tuottamisen kannalta tarpeellisia (Henkilötietolaki 9 §)

 - Haka-palvelusopimus, liite 5, kohta 4 SAML-palvelun rekisteröiminen luottamusverkostoon

SAML-tekniikaan hyvin perehtynyt IT-asiantuntija toteuttaa teknisesti federoinnin muutaman kalenteriviikon kuluessa. Laajasti käytettyjä SAML-tuotteita, kuten Shibbolethia käytettäessä tekninen käyttöönotto voidaan tehdä muutamassa päivässä. Sovelluksen autentikaation ja sessionhallinnan toteutuksesta riippuu, miten helppoa sen federointi on. Projektin aikataulutuksessa on myös huomioitava muut ennakoivat työvaiheet, kuten tuotevalinta, henkilötietojen käsittelyn suunnittelu tai nykyisten käyttäjätilien liittäminen Haka-kirjautumisesta saatavaan identiteettiin. Joidenkin sovellusten kohdalla tai hankalien riippuvuussuhteiden hallitsemiseksi joskus joudutaan valmistautumaan laajemmin ja varamaan aikaa huomattavasti tässä mainittua enemmän.

Olemme tilaamassa järjestelmää, jossa ominaisuutena on federoitu kirjautuminen. Pitääkö toimittajan liittyä Haka-kumppaniksi? Kenen nimiin uusi palvelu rekisteröidään?

Haka-kumppaniksi liittyminen on maksutonta toimittajalle, mikäli järjestelmä tehdään jonkin Haka-jäsenen toimeksiannosta. Palvelu voidaan myös rekisteröidä järjestelmän tilaajan nimiin, jos niin halutaan. Rekisteröivä taho on oikeutettu tekemään muutoksia palvelun Haka-tietoihin. Rekisteröinti kannattaa yleensä käytännön syistä tehdä sen tahon nimiin, joka vastaa järjestelmän päivittäisestä ylläpidosta. Asiaa voi tarkastella myös siitä näkökulmasta, kuka vastaa palvelun muodostamasta henkilörekisteristä ja miten palvelun henkilötietojen käsittely on suunniteltu toteutettavan.

Jos järjestelmä tulee vain yhden Haka-jäsenen käyttöön, rekisteröinti voidaan suorittaa harkinnan mukaan joko toimittajan tai tilaajan nimiin. Jos järjestelmästä tulee useille Haka-jäsenille oma instanssi, yleensä tällöin kannattaa toimittajan liittyä Haka-kumppaniksi.

Määrittelemme järjestelmää X. Onko olemassa keskitetty rekisteri korkeakouluopiskelijoista / korkeakoulujen henkilökunnasta, jonka perusteella käyttäjätunnistus ja/tai käyttövaltuutus voitaisiin toteuttaa?

Haka on hajautettu järjestelmä, jossa kukin korkeakoulu vastaa omien käyttäjiensä tiedoista.Haka näyttää teknisesti palvelun kannalta yhdeltä järjestelmältä, mutta ei ole olemassa yhtä keskitettyä rekisteriä, josta käyttäjätietoja voi poimia. 

Käyttäjistä saatavilla olevien tietojen määritykset löytyvät FunetEduPerson-skeemasta. Osa tiedoista on pakollisia, joita kaikkien Haka-jäsenten on ylläpidettävä, osa perustuu vapaaehtoisuuteen.

Palvelun on mahdollista määrittää myös omia käyttäjätietoja valtuutuksen tueksi. Tällöin on kuitenkin huomioitava, että käyttäjätiedot tulee tallentaa Hakaj-jäsenen järjestelmiin ja käyttäjätietojen ylläpitoon on oltava mekanismit. Yksittäisen palvelun voi olla vaikea saada Haka-jäsentä suostumaan tallettamaan ja ylläpitämään yhtä palvelua koskevia käyttäjätietoja. 

Mitä tietoja resurssirekisteriin vähintään täytyy syöttää uudesta palvelusta (Service Provider)?

Palvelun rekisteröimiseksi testiin tarvitaan vähintään:

• Palvelun nimi
• Yksilöllinen entity id
  • testiin ei hyväksytä localhost entity id:tä, vaan id:n on oltava yksilöivä
    
  • entity id:ksi suositellaan rekisteröijän virallisesti omistama URI. Esim. yleisesti tunnetun rekisterinpitäjän myöntämä verkkotunnus (domain name; esim. suomalaisen .fi -verkkotunnuksen rekisterinpitäjä on Viestintävirasto)
  • entity id:n ei tarvitse olla esim. toimiva www-sivu, vaan se on tarkoitettu yksilöimään palvelu muista
• SAML-viestien suojaamiseen tarkoitettu varmenne (huomaa, että varmenteen syöttämiseksi  SP Basic Information -osiossa on rastitettava kohta "Encrypt Assertions")
  • ei tarvitse olla sama, jota käytetään HTTP-liikenteen suojaamisen, mutta voi olla sama
• tekninen kontakti
• jos halutaan testi-idp:n luovuttavan attribuutteja, on resurssirekisterin syöttölomakkeelle kirjattava attribuuttipyynnöt
• toimiva assertion consumer service URL(riittää, että testaajan selaimelta on pääsy kyseiseen URL:iin)
  • URL:n on oltava yksilöllinen ja kohteen liittyä kyseiseen palveluun
  • muihin palveluihin (tai localhostiin) viittaavia URL:eja ei hyväksytä edes testiin
  • URL:n ei ole pakko resolvoida Internetin yleisessä DNS-palvelussa
  • Hakassa on käytössä vain HTTP-POST, joskin muita voidaan tarvita, jos samaa palvelua käytetään myös muualla, kuin Hakassa
• Jos rekisteröijän organisaatiota ei ole lueteltu resurssireksiterissä, voi testivaiheessa käyttää: "Haka testiorganisaatio"

Palvelun rekisteröimiseksi Hakaan tarvitaan edellisten lisäksi:

Historia

Mistä Haka nimi tulee ja miten se kirjoitetaan?

Haka-luottamusverkoston nimi om muotoutunut 2000-luvun alussa olleesta Hakemistot käyttäjähallinnossa -projektista. Siinä selvitettiin LDAP-hakemistojen yhteiskäyttöä korkeakouluissa. Projektissa alettiin tutkia myös lupaavaa Shibboleth-tekniikkaa. Aiemmin oli selvitetty mm. HST-korttien käyttöä korkeakoulissa sekä oli Käyttäjät ja todentaminen -projekti käyttäjätunnistamiseen liittyen.

Shibboleth-tekniikan ympärille muodostui korkeakoulujen käyttöön käyttäjätunnistamisen luottamusverkosto, jonka nimeksi jäi Haka. Haka nimenä oli tullut projektin kautta tutuksi laajemminkin, joten se katsottiin sopivaksi. Sittemmin Shibboleth-tekniikasta siirryttiin standardoituun SAML-protokollaan, mutta nimi Shibboleth elää edelleen ohjelmistona ja usein myös itse toimintaan viittaavana.

Haka kirjoitetaan isolla alkukirjaimella Hakan ollessa vakiintunut nimi. Alunperin sen voi ajatella olleen lyhennesana, joiden kirjoittamisesta on ohje Kotimaisten kielten keskulsella https://www.kotus.fi/nyt/kolumnit_artikkelit_ja_esitelmat/hyvaa_virkakielta/hyvaa_virkakielta_-palstan_arkisto_%282002_2014%29/lyhennesanat

Liittyminen ja rekisteröinti

Asiakkaamme haluaisi Haka-kirjautumisen palveluun mahdollisimman nopeasti, mutta liittymisprosessi on kesken. Miten sitä voisi nopeuttaa?

Ohjausryhmä hyväksyy Haka-kumppanit ja tämän lisäksi palvelusopimuksen allekirjoituskierrossa CSC:llä kuluu aikaa. Tätä prosessia ei voi nopeuttaa, vaan projektissa siihen kannattaa varata kalenteriaikaa 4-6 viikkoa (yleensä sopimiskierto on kuitenkin valmis jo muutamassa viikossa). Liittymisprosessi on kuvattu omalla sivullaan.

Samanaikaisesti sopimusprosessin edetessä Haka-kirjautumisen käyttöönottoa voi edistää teknisesti toteuttamalla ja testaamalla palvelun Haka-integraatio valmiiksi. Kaikki Hakaan liitettävät entiteetit testataan vasten operaattorin testipalvelimia ennen tuotantometadataan lisäämistä. Operaattori varmistaa ennen tuotantometadataan siirtämistä, että on onnistuneesti toteutettu kirjautuminen vasten testipalvelinta. Entiteetin SAML-profiilinmukaisuus tarkistetaan pintapuolisesti.

Testaamisen lisäksi tarvitaan myös vahvistus kumppanin tai jäsenen hallinnolliselta yhteyshenkilöltä. Valmistele yhteyshenkilö jo etukäteen, että hän arvioi vastuulleen kuuluvat asiat ajoissa ennen tuotantoon siirtymistä:

Luottamusverkoston jäsenen tai kumppanin hallinnollinen yhteyshenkilö varmistaa erityisesti, että

• • palvelu ei ole ristiriidassa luottamusverkoston toiminnan tarkoituksen kanssa (Liite 2: ”Haka-luottamusverkoston toiminnan tarkoitus on tukea korkeakoulujen ja tutkimuslaitosten toimintaa”)
  • hakemuksessa esitetyt henkilötiedot, joita palvelu katsoo tarvitsevansa loppukyttäjistä, ovat palvelun tuottamisen kannalta tarpeellisia (Henkilötietolaki 9 §)

 - Haka-palvelusopimus, liite 5, kohta 4 SAML-palvelun rekisteröiminen luottamusverkostoon

SAML-tekniikaan hyvin perehtynyt IT-asiantuntija toteuttaa teknisesti federoinnin muutaman kalenteriviikon kuluessa. Laajasti käytettyjä SAML-tuotteita, kuten Shibbolethia käytettäessä tekninen käyttöönotto voidaan tehdä muutamassa päivässä. Sovelluksen autentikaation ja sessionhallinnan toteutuksesta riippuu, miten helppoa sen federointi on. Projektin aikataulutuksessa on myös huomioitava muut ennakoivat työvaiheet, kuten tuotevalinta, henkilötietojen käsittelyn suunnittelu tai nykyisten käyttäjätilien liittäminen Haka-kirjautumisesta saatavaan identiteettiin. Joidenkin sovellusten kohdalla tai hankalien riippuvuussuhteiden hallitsemiseksi joskus joudutaan valmistautumaan laajemmin ja varamaan aikaa huomattavasti tässä mainittua enemmän.

Olemme tilaamassa järjestelmää, jossa ominaisuutena on federoitu kirjautuminen. Pitääkö toimittajan liittyä Haka-kumppaniksi? Kenen nimiin uusi palvelu rekisteröidään?

Haka-kumppaniksi liittyminen on maksutonta toimittajalle, mikäli järjestelmä tehdään jonkin Haka-jäsenen toimeksiannosta. Palvelu voidaan myös rekisteröidä järjestelmän tilaajan nimiin, jos niin halutaan. Rekisteröivä taho on oikeutettu tekemään muutoksia palvelun Haka-tietoihin. Rekisteröinti kannattaa yleensä käytännön syistä tehdä sen tahon nimiin, joka vastaa järjestelmän päivittäisestä ylläpidosta. Asiaa voi tarkastella myös siitä näkökulmasta, kuka vastaa palvelun muodostamasta henkilörekisteristä ja miten palvelun henkilötietojen käsittely on suunniteltu toteutettavan.

Jos järjestelmä tulee vain yhden Haka-jäsenen käyttöön, rekisteröinti voidaan suorittaa harkinnan mukaan joko toimittajan tai tilaajan nimiin. Jos järjestelmästä tulee useille Haka-jäsenille oma instanssi, yleensä tällöin kannattaa toimittajan liittyä Haka-kumppaniksi.

Määrittelemme järjestelmää X. Onko olemassa keskitetty rekisteri korkeakouluopiskelijoista / korkeakoulujen henkilökunnasta, jonka perusteella käyttäjätunnistus ja/tai käyttövaltuutus voitaisiin toteuttaa?

Haka on hajautettu järjestelmä, jossa kukin korkeakoulu vastaa omien käyttäjiensä tiedoista.Haka näyttää teknisesti palvelun kannalta yhdeltä järjestelmältä, mutta ei ole olemassa yhtä keskitettyä rekisteriä, josta käyttäjätietoja voi poimia. 

Käyttäjistä saatavilla olevien tietojen määritykset löytyvät FunetEduPerson-skeemasta. Osa tiedoista on pakollisia, joita kaikkien Haka-jäsenten on ylläpidettävä, osa perustuu vapaaehtoisuuteen.

Palvelun on mahdollista määrittää myös omia käyttäjätietoja valtuutuksen tueksi. Tällöin on kuitenkin huomioitava, että käyttäjätiedot tulee tallentaa Hakaj-jäsenen järjestelmiin ja käyttäjätietojen ylläpitoon on oltava mekanismit. Yksittäisen palvelun voi olla vaikea saada Haka-jäsentä suostumaan tallettamaan ja ylläpitämään yhtä palvelua koskevia käyttäjätietoja. 

Mitä tietoja resurssirekisteriin vähintään täytyy syöttää uudesta palvelusta (Service Provider)?

Palvelun rekisteröimiseksi testiin tarvitaan vähintään:

• Palvelun nimi
• Yksilöllinen entity id
  • testiin ei hyväksytä localhost entity id:tä, vaan id:n on oltava yksilöivä
    
  • entity id:ksi suositellaan rekisteröijän virallisesti omistama URI. Esim. yleisesti tunnetun rekisterinpitäjän myöntämä verkkotunnus (domain name; esim. suomalaisen .fi -verkkotunnuksen rekisterinpitäjä on Viestintävirasto)
  • entity id:n ei tarvitse olla esim. toimiva www-sivu, vaan se on tarkoitettu yksilöimään palvelu muista
• SAML-viestien suojaamiseen tarkoitettu varmenne
• tekninen kontakti
• jos halutaan testi-idp:n luovuttavan attribuutteja, on resurssirekisterin syöttölomakkeelle kirjattava attribuuttipyynnöt
• toimiva assertion consumer service URL(riittää, että testaajan selaimelta on pääsy kyseiseen URL:iin)
  • URL:n on oltava yksilöllinen ja kohteen liittyä kyseiseen palveluun
  • muihin palveluihin (tai localhostiin) viittaavia URL:eja ei hyväksytä edes testiin
  • URL:n ei ole pakko resolvoida Internetin yleisessä DNS-palvelussa
  • Hakassa on käytössä vain HTTP-POST, joskin muita voidaan tarvita, jos samaa palvelua käytetään myös muualla, kuin Hakassa
• Jos rekisteröijän organisaatiota ei ole lueteltu resurssirekisterissä, voi testivaiheessa käyttää: "Haka testiorganisaatio"

Palvelun rekisteröimiseksi Hakaan tarvitaan edellisten lisäksi:

• palvelun nimi (kielillä fi, sv, en)
• laadukas kuvaus palvelusta (kielillä fi, sv, en - katso lisää: Metadatan käyttöliittymäelementit)
• tekninen ja support-kontaktit
• jos palvelu pyytää yksilöiviä henkilötietoja, tarvitaan tietosuojaselosteen URL
  • tietosuojaseloste on oltava
• palvelun nimi (kielillä fi, sv, en)
• laadukas kuvaus palvelusta (kielillä fi, sv, en - katso lisää: Metadatan käyttöliittymäelementit)
• tekninen ja support-kontaktit
• jos palvelu pyytää yksilöiviä henkilötietoja, tarvitaan tietosuojaselosteen URL
  • tietosuojaseloste on oltava julkisesti Internetissä saatavilla
• jos palvelussa käytetään Hakan keskitettyä DS-palvelua, tarvitaan DS-response URL
• attribuuttipyynnöt on perusteltava
  • organisaation hallinnollinen Haka-yhteyshenkilö tarvitsee tietoa tehdessään valistuneen päätöksen hyväksyä palvelu liitettäväksi Hakaan

...

SAML-kirjautumisen yhteydessä sinulla on istunto paitsi omassa tunnistuslähteessäsi, myös niissä palveluissa, joihin olet kirjautunut tekniikkaa käyttäen. Näiden istuntojen pituudet vaihtelevat. Jokainen organisaatio ja palvelu määrittelee istunnon maksimipituuden (session lifetime) ja ajan, jonka se voi olla joutilaana (session inactivity). Palvelu voi myös erikseen vaatia uudelleenkirjautumista siitäkin huolimatta, että istunto tunnistuslähteellä on vielä voimassa.

Olen etätöissä kotona / ulkomailla / nettikahvilassa / hotellissa ja joudun jatkuvasti kirjautumaan uudelleen. Miksi istunnot eivät säily?

Palvelu Palvelu ei tarjoa mahdollisuutta kirjautua ulos. Miten varmistan, että muut eivät pääse tietoihin käsiksi?

...

Sallittaessa pääsy vain joistakin organisaatioista pääsy palveluun, on suositeltavaa toteuttaa tunnistuspalvelimen valinta palvelun omassa käyttöliittymässä. Palveluun siis tehdään tunnistuspalvelimen valintapalvelu eikä käytetä keskitettyä Haka DS:ia, jossa on listattuna kaikki organisaatiot. Tällä vältytään tarpeettomilta tunnistuksilta ei-sallittujen organisaatioden käyttäjissä.

Huonoin vaihtoehto on metadatatasolla estää luottosuhteiden muodostuminen tiettyihin organisaatiohin. Tässä tilanteessa on vaarana hallitsemattomat virhetilanteet käyttäjien kirjautumisissa. Jos metadatatasolla estetään luottosuhde johonkin organisaatioon, on erittäin tärkeää huolehtia tunnistuspalvelimen valinnasta palvelun omassa käyttöliittymässä, jotta vältytään luottosuhteeseen perustuvista virheistä.

Päivitin IdP:n versioon neljä ja joihinkin palveluihin estyi pääsy

Shibboleth IdP4:ssa on oletuksena käytössä GCM-algoritmi XML-viestien salaamisessa. Tätä algoritmia eivät kaikki varsinkaan vanhemmat palvelut Hakassa tue. Ensimmäinen ja paras vaihtoehto on, että palvelu päivittäisi SP:nsa tukemaan GCM-algoritmia

Mikäli SP:ssa tukea ei saada toteutettua, tunnistuspalvelimen voi kuitenkin helposti konfiguroida tukemaan myös vanhempia algoritmejä, joita ei kuitenkaan suositella käytettäväksi laajemmin. Tarkat ohjeet IdP:n konfigurointiin löytyvät: https://wiki.shibboleth.net/confluence/display/IDP4/GCMEncryption

Alla on listattu palveluita (Haka, eduGAIN), joiden tiedämme etteivät tue GCM-algoritmia salauksessa. Voit ilmoittaa omista havainnoistasi haka@csc.fi. 

tunnistuspalvelimen valinta palvelun omassa käyttöliittymässä. Palveluun siis tehdään tunnistuspalvelimen valintapalvelu eikä käytetä keskitettyä Haka DS:ia, jossa on listattuna kaikki organisaatiot. Tällä vältytään tarpeettomilta tunnistuksilta ei-sallittujen organisaatioden käyttäjissä.

Huonoin vaihtoehto on metadatatasolla estää luottosuhteiden muodostuminen tiettyihin organisaatiohin. Tässä tilanteessa on vaarana hallitsemattomat virhetilanteet käyttäjien kirjautumisissa. Jos metadatatasolla estetään luottosuhde johonkin organisaatioon, on erittäin tärkeää huolehtia tunnistuspalvelimen valinnasta palvelun omassa käyttöliittymässä, jotta vältytään luottosuhteeseen perustuvista virheistä.

Päivitin IdP:n versioon neljä ja joihinkin palveluihin estyi pääsy

Shibboleth IdP4:ssa on oletuksena käytössä GCM-algoritmi XML-viestien salaamisessa. Tätä algoritmia eivät kaikki varsinkaan vanhemmat palvelut Hakassa tue. Ensimmäinen ja paras vaihtoehto on, että palvelu päivittäisi SP:nsa tukemaan GCM-algoritmia

Mikäli SP:ssa tukea ei saada toteutettua, tunnistuspalvelimen voi kuitenkin helposti konfiguroida tukemaan myös vanhempia algoritmejä, joita ei kuitenkaan suositella käytettäväksi laajemmin. Tarkat ohjeet IdP:n konfigurointiin löytyvät: https://wiki.shibboleth.net/confluence/display/IDP4/GCMEncryption

Alla on listattu palveluita (Haka, eduGAIN), joiden tiedämme etteivät tue GCM-algoritmia salauksessa. Voit ilmoittaa omista havainnoistasi haka@csc.fi. 

<MetadataProvider backingFile="%{idp.home}/metadata/haka-metadata.xml" id="HTTPHakaMetadata" maxRefreshDelay="PT2H" metadataURL="https://haka.funet.fi/metadata/haka-metadata.xml" refreshDelayFactor="0.5" xsi:type="FileBackedHTTPMetadataProvider">
  <MetadataFilter certificateFile="%{idp.home}/credentials/haka-sign-v5.pem" xsi:type="SignatureValidation"/>
  <MetadataFilter xsi:type="EntityRoleWhiteList">
    <RetainedRole>md:SPSSODescriptor</RetainedRole>
  </MetadataFilter>
  <MetadataFilter xsi:type="Algorithm">
    <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <Entity>http://fse.eduuni.fi/adfs/services/trust</Entity>
	<Entity>https://login.aka.fi:443/uas</Entity>
    <Entity>https://e-learn.csc.fi/saml/sp</Entity>
    <Entity>http://adfs.eta.csc.fi/adfs/services/trust</Entity>
    <Entity>http://fs.findata.csc.fi/adfs/services/trust</Entity>
    <Entity>https://virkailija.opintopolku.fi/service-provider-app/saml/metadata/alias/hakasp</Entity>
	<Entity>https://auth.oamk.fi/simplesaml/module.php/saml/sp/metadata.php/haka</Entity>
	<Entity>https://video.lamk.fi</Entity>
 	<Entity>https://savonia.alma.exlibrisgroup.com/mng/login</Entity>
    <Entity>https://moodle.karelia.fi/auth/saml2/sp/metadata.php<

<MetadataProvider backingFile="%{idp.home}/metadata/haka-metadata.xml" id="HTTPHakaMetadata" maxRefreshDelay="PT2H" metadataURL="https://haka.funet.fi/metadata/haka-metadata.xml" refreshDelayFactor="0.5" xsi:type="FileBackedHTTPMetadataProvider">
  <MetadataFilter certificateFile="%{idp.home}/credentials/haka-sign-v5.pem" xsi:type="SignatureValidation"/>
  <MetadataFilter xsi:type="EntityRoleWhiteList">
    <RetainedRole>md:SPSSODescriptor</RetainedRole>
  </MetadataFilter>
  <MetadataFilter xsi:type="Algorithm">
    <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <Entity>http://fse.eduuni.fi/adfs/services/trust</Entity>
    <Entity>https://filesenderwww.funetjobiili.fi<fi/</Entity>
    <Entity>https://newtestihallinta.webropolsurveysamkvalintakoe.com/shibboleth-sp/</fi</Entity>
	    <Entity>https://loginhallinta.aka.fi:443/uas<amkvalintakoe.fi</Entity>
    <Entity>https://e-learn.csc.fi/saml/sp</hallinta.korkeakouluun.fi</Entity>
    <Entity>http<Entity>https://adfsmooc.etahelsinki.csc.fi/adfsauth/saml2/servicessp/trust<metadata.php</Entity>
    <Entity>http://fs.findatathinking1.csc.ficom/adfs/services/trust</Entity>
    <Entity>https://virkailijacertia.opintopolkuefectecloud.fi/service-provider-app/saml/metadata/alias/hakasp</Entity>
	com:443/idm</Entity>
    <Entity>https://authrekry.oamksaima.fi/simplesaml/module.php/saml/sp/metadata.php/haka<vismahakasp</Entity>
	    <Entity>https://videowww.lamkkopi.fi<fi/</Entity>
 	<Entity>https   <Entity>https://savoniaipr.alma.exlibrisgroup.com/mng/login<mrooms.net/auth/saml2/sp/metadata.php</Entity>
     <Entity>https://moodlevirkailija.kareliatestiopintopolku.fi/auth/saml2/sp/metadata.php</Entity>service-provider-app/saml/metadata/alias/hakasp</Entity> 
    <Entity>https://wwwedu.jobiiliflinga.fi/<saml</Entity>
  < </MetadataFilter>
 </MetadataProvider>

<MetadataProvider backingFile="%{idp.home}/metadata/edugain-metadata.xml" id="HTTPEdugainMetadata" maxRefreshDelay="PT2H" metadataURL="https://haka.funet.fi/edugain-nightly/gen-edugain/idp-[X]-metadata-eduGain.xml" refreshDelayFactor="0.5" xsi:type="FileBackedHTTPMetadataProvider">
  <MetadataFilter certificateFile="%{idp.home}/credentials/haka-edugain-sign.csc.fi.2020.pem" xsi:type="SignatureValidation"/>
  <MetadataFilter xsi:type="EntityRoleWhiteList">
    <RetainedRole>md:SPSSODescriptor</RetainedRole>
  </MetadataFilter>
  <MetadataFilter xsi:type="Algorithm">
    <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <Entity>http://adfs.eta.csc.fi/adfs/services/trust</Entity>
    <Entity>http://fs.findata.csc.fi/adfs/services/trust</Entity>
    <Entity>https://terena.org/sp</Entity>
  </MetadataFilter>
</MetadataProvider>

...

SAML-varmenne julkaistaan muille verkoston entiteeteille Haka-metadatassa. Hakassa metadatan normaali julkaisusykli on noin kerran kahden viikon aikana. Metadatan julkaisua voidaan aikaistaa painavasta syystä. Hakassa on lähes 200 450 entiteettiä, joiden varmenteet uusitaan säännöllisesti. Varmenteen vanhenemiseen on mahdollista varautua etukäteen ja tästä syystä varmenteen vanhenemista ei yleisesti katsota painavaksi syyksi poiketa normaalista metadatan julkaisusyklistä.

...