Yleisiä huomioita SAML-entiteettien muutoksenhallinnassa
Entity Identifierin pysyvyys
Haka-operaattori viittaa seuraavissa suosituksissaan Shibboleth -projektin suosituksiin entiteettien nimeämisessä (entityId:n käytössä): https://wiki.shibboleth.net/confluence/display/SHIB/EntityNaming.
EntityId:tä käytetään opaakkien tunnisteiden (pysyvä nimitunniste - Persistent Name Identifier, eduPersonTargetedId) luomisessa. Opaakit tunnisteet muuttuvat entityId:n muuttuessa. EntityId:n muuttuminen voi myös joissakin tapauksissa aiheuttaa tarpeetonta ylläpitotyötä niissä järjestelmissä, jotka luottavat rekisteröitävään palveluun. Näistä syistä entityId:n suositellaan olevan mahdollisimman pysyvä ja muuttuvan vain perustellusta syystä.
EntityId:n suositellaan olevan enintään 1024 merkin pituinen URI. Yksilöllisyyden varmistamiseksi suositellaan käyttämään rekisteröivän organisaation omistamaa nimiavaruutta (esim. URL-muotoiseen verkkotunnukseen perustuva tai urn:oid). Minkään palvelun ei odoteta vastaavan entityId:n URL:n määrittämästä osoitteesta. Koska host-nimet muuttuvat, ei suositella rekisteröitävän palvelun tuottavan palvelimen nimeen perustuvaa entityId:tä.
Entity Identifierin nimenselvitys (Resolution)
EntityId:n määrittämän URI:n ei tarvitse resolvoitua (esim. ei tarvitse olla Internetin DNS-järjestelmässä), mutta sen suositellaan kuuluvan rekisteröijän omistamaan nimiavaruuteen. Koska entityId:n on pysyttävä pitkään muuttumattomana, rekisteröijän on syytä huomioida, että SAML2:ssa on mahdollista määritellä metadatan nouto käyttäen entityId:n määrittämää nimeä. Tällainen menetelmä ei ole Hakassa toistaiseksi käytössä, mutta on mahdollista, että se tulee käyttöön ajan kuluessa.
Henkilötietojen käsittelytarkoituksen muuttuminen palvelussa (SP)
Haka-palvelusopimuksen liitteessä 3 todetaan erityisistä vaatimuksista palveluntarjoajille:
Jos henkilötietojen käsittelytarkoitusta palvelussa muutetaan, toimitaan kuin jos palvelu kytkettäisiin luottamusverkostoon uutena palveluna.
Henkilötietojen käsittelytarkoituksen muuttuessa palvelun entityId suositellaan vaihdettavan. Palvelun vastaanottamat opaakit tunnisteet muuttuvat ja palveluun suhtaudutaan luottamusverkosssa, kuin se olisi uusi, toinen palvelu.
Haka-metadatan päivitystahti
Haka-metadata päivitetään keskimäärin kerran kahden viikon kuluessa. Painavista syistä päivistystä voidaan aikaistaa. Päivitystahti ei myöskään noudata tiettyä ennalta määritettyä aikataulua. Kaikissa muutoksissa on huomoitava, että muutos tulee voimaan vasta seuraavassa metadatajulkaisussa siitä, kun muutos on operaattorin toimesta vahvistettu resurssirekisterissä. Ajoittain myös Haka-operoinnin helpdesk-palvelussa voi olla ruuhkaa, jolloin muutoksien käsittelyssä voi olla viiveitä.
Välittämästi metadataan tehdään tietoturvam varmistavat muutokset, kuten varmenteen poistaminen silloin, kun siihen liittyvä salausavain on joutunut vääriin käsiin tai entiteetin tilapäinen poistaminen metadatast jos se on esimerkiksi murrettu.
Useimpiin muutoksiin on mahdollista varautua ja valmistautua hyvissä ajoin niin, että metadata ehditään päivittää normaalin julkaisurytmin mukaisesti.
Tunnistuslähteen yliheitossa huomioitavaa
Eppn pysyvyys
EduPersonPrincipalName on scoped-attribuutti, jonka alkuosa yksilöi käyttäjän loppuosan määrittämässä toimialueessa. Palvelujen velvollisuus on tarkistaa, että attribuuttiluovutuksena saatu skooppi vastaa IdP:n metadataan ilmoitettua. IdP:lle voi ilmoittaa metadataan useamman skoopin. Näin esimerkiksi organisaatioiden fuusioituessa käyttäjien eppn-attribuuttit voivat pysyä ennallaan. Operaattorin tulkintaohjeen mukaisesti eppn-attribuutti saa muuttua vain painavista syistä. Jos attribuutti muuttuu, on organisaation velvollisuus tiedottaa tästä palveluille. Tiedottamisen tueksi Haka-wikissä on sivu: eppn-muutoksista. Muutoksen läpikäyneen organisaation on kyseiselle sivulle tai sen alasivulle kirjattava miten ja koska attribuutin arvot muuttuvat.
EPPN:n käytössä on myös syytä muistaa 24 kuukauden kierrätyssääntö. Eppn-arvoa ei saa luovuttaa uudelle käyttäjälle ennen kuin 24 kuukautta on kulunut sen vapautumisesta. Toisaalta, palvelujen on oletettava, että eppn on vaihtanut omistajaa, jos sitä ei ole käytettty 24 kuukauteen. Käytännössä siis esim. organisaatioiden fuusioituessa vanhat skoopit poistuvat organisaation käytöstä vasta, kun 24 kuukautta on kulunut viimeisen vanhaa skooppia käyttäneen käyttäjän deaktivoitumisesta.
Opaakkien nimiattribuuttien pysyvyys
Opaakkeja nimiattribuutteja ovat eduPersonTargetedId (eptid) ja SAML-assertion subjectissa välitettävä pysyvä nimitunniste (persistent nameidentifier). Jokaiselle henkilölle luodaan yksi opaakki tunniste jokaista IdP-SP yhdistelmää kohden. Näin siis yhden IdP:n kahdelle eri SP:lle luovuttamat nimitunnisteet ovat erilaisia sen varmistamiseksi, että palvelut eivät voi identifioida käyttäjää vertailemalla saamiaan nimitunnisteita. Nimitunniste voidaan luoda ensimmäisen kirjautumisen yhteydessä ja tallentaa IdP:n tietokantaan. Nimitunnisteet voidaan myös tallentaa henkilöhakemistoon, mutta tällöinkin on huolehdittava vaatimuksesta, jossa jokaiselle palvelulle on käyttäjästä luovutettava erilainen nimitunniste.
Nimitunnisteet ovat pysyviä, eli ne eivät saa muuttua. Nimitunnisteen muuttuminen aiheuttaa, että käyttäjä menettää käyttäjäprofiilinsa sellaisessa palvelussa, joka tukeutuu nimitunnisteeseen. Nimitunnisteet ovat sidoksissa SP:n ja IdP:n entityId:hen, joten toisen muuttuessa myös nimitunniste muuttuu. Tästä syystä IdP:n yliheitossa entityId:n ei pitäisi muuttua.
Palvelun (SP) palvelinvaihdos
Palvelun (SP) assertion consumer service URL (ACS-URL) voi muuttua esimerkiksi, kun palvelu siirretään alustalta (palvelimelta) toiselle. Tässä yhteydessä ei ole tarpeen muuttaa muita palvelusta metadataan syötettyjä tietoja ja esim. palvelun entityId pysyy entisellään. EntityId:n säilyttäminen varmistaa, että opaakit nimitunnisteet säilyvät ja käyttäjät pääsevät omiin käyttäjäprofiileihinsa omilla tunnisteillaan. Samasta syystä entityId:n ei pitäisi perustua palvelualustan hostnimeen.
ACS-URL:n muutos tehdään seuraavalla prosessilla
- Testataan palvelu uudessa osoitteessa / uudella alustalla
- Lisätään uusi ACS-URL Resurssirekisteriin palvelun tietoihin
- Odotetaan metadatan päivittymistä
- Aikaisintaan 24 tunnin kuluttua metadatan päivittymisestä ohjataan käyttäjät palvelun uuteen osoitteeseen
- Kun palvelun toiminta uudessa osoitteessa on varmistettu, poistetaan vanha ACS-URL resurssirekisteristä