Käyttäjähallinnon vähimmäisvaatimukset ja soveltamisohjeet

Dokumentin tarkoitus

Tämä dokumentti on Haka-infrastruktuurin operaattorin tekemä tulkintaohje Haka-palvelusopimukselle ja sen liitteessä 3. esitetyille, kotiorganisaatiota koskeville vaatimuksille. Lisäksi dokumentissa täsmennetään joitain liitteessä määriteltyjä asioita sekä funetEduPerson-skeeman käyttöä.

Dokumentin päämäärä on esittää operaattorin toimintalinja kotiorganisaation sisäisen käyttäjähallinnon arvioinnissa ja taata korkeakoulujen tasapuolinen kohtelu.

Dokumentin kohderyhmä

• korkeakoulussa käyttäjähallinnosta vastaavat tahot (atk-keskus tai vastaava)
• palveluntarjoajat, jotka haluavat liittyä käyttäjän tunnistamisinfrastruktuuriin

Tulkintaohjeet

1. Tulkinta: käyttäjätietojen ajantasaisuus

Tausta:

• Yleisen tietosuoja-asetuksen 5 artiklan 1 kohdan d alakohta: "henkilötietojen on oltava täsmällisiä ja tarvittaessa päivitettyjä; on toteutettava kaikki mahdolliset kohtuulliset toimenpiteet sen varmistamiseksi, että käsittelyn tarkoituksiin nähden epätarkat ja virheelliset henkilötiedot poistetaan tai oikaistaan viipymättä (”täsmällisyys”);" Lisäksi, 5 artiklan 2 kohta: "Rekisterinpitäjä vastaa siitä, ja sen on pystyttävä osoittamaan se, että 1 kohtaa on noudatettu (”osoitusvelvollisuus”)."
• Haka-palvelusopimus, liite 3, kohta 2.3.6: "Kotiorganisaatiot varmistavat asiaankuuluvaa huolellisuutta noudattaen, että vain virheettömiä ja ajantasaisia (...) henkilötietoja luovutetaan palveluntarjoajille"
• Haka-ohjausryhmän tulkinta 26.5.2004:  "Tieto käyttäjän käyttöoikeuden päättymisestä tulee päivittyä mielellään välittömästi, kuitenkin viimeistään viikon sisällä, sisältäen mahdollisen armonajan (grace). Käytännössä tämä edellyttää käyttäjähallinnon kytkemistä organisaation perusrekistereihin, kuten opiskelija- ja henkilökuntarekisteriin."

Tulkinta/ajantasaisuus:

• Kotiorganisaation Identity Provider (IdP) -palvelin voidaan kyllä rekisteröidä Haka-infrastruktuuriin, mutta se saa tarjota käyttäjistä vain sellaisia attribuutteja, jotka ovat ajan tasalla IdP:n käyttämässä käyttäjätietokannassa. Jos esimerkiksi käyttäjätietokannan ja opiskelijarekisterin väliltä puuttuu kytkentä, ei IdP saa tarjota Haka-infrastruktuuriin käyttäjien opiskelijaroolia koskevia attribuutteja (esim. koulutusohjelma, tavoitetutkinto tai eduPersonAffiliation=student)
• Haka-palvelusopimuksen liitten 3 kohdan  2.3.5. mukaan kuitenkin vähintään funetEduPerson-skeeman MUST-attribuuteille on annettava arvo; niitä ovat skeman versiossa 2.0 common name, surname, displayName, eduPersonPrincipalName, schacHomeOrganization, schacHomeOrganizationType, joista kaksi jälkimmäistä lienevät samat kaikillä käyttäjille IdP:ssä
• Palveluntarjoajan ei ole syytä olettaa, että pelkkä "shibboleth-tunnistamisen onnistuminen" takaisi mitään muuta kuin että henkilöllä on käyttäjätunnus kyseisessä organisaatiossa. Jotkut korkeakoulut voivat antaa käyttäjätunnuksia alumneille, emerituksille tai kirjaston asiakkaina oleville "kadunmiehille".
• Toisaalta: palveluntarjoaja voi vaatia kotiorganisaatiolta palvelun kannalta tarpeellisia attribuutteja (esim. eduPersonAffiliation=student) käyttöoikeuksien toteamista varten. Kotiorganisaatio, joka ei voi tarjota palvelun vaatimia attribuuttia, rajautuu ulos kyseisestä palvelusta.

Tulkinta/perusrekisterikytkentä:

• kytkentä organisaation perusrekistereihin voi olla joko tekninen (esim. skripti välittää perusrekisterin muutokset käyttäjätietokantaan) tai perustua organisaation toimintaprosesseihin (esim. opintoasiainhallinnon virkailija sulkee opiskelijan käyttäjätunnuksen samalla kun opiskelija tulee hakemaan tutkintotodistusta, tai päivittää opiskelijan ilmoittaman muuttuneen kotiosoitteen paitsi opiskelijarekisteriin, myös käyttäjätietokantaan). Jos käyttäjätunnuksen sulkeutuminen taataan toimintaprosessin avulla, tulee toimintaprosessin olla määrämuotoinen ja dokumentoitu, ja sitä tulee myös tosiasiallisesti noudattaa.
• jos käyttäjällä ei ole organisaatiossa perusrekisteriä (esim. Suomen Akatemian palkkaama tutkija, joka työskentelee tutkimusryhmässä yliopiston laitoksella), tulee kotiorganisaation taata käyttäjän käyttäjätunnuksen tai roolitiedon sulkeutuminen äärellisessä ajassa tekemällä siitä määräaikainen.

Rajaus:

• nämä vaatimukset koskevat vain Haka-infrastruktuurin palveluntarjoajien suuntaan näkyvää toimintaa. Haka-infrastruktuuri ei ota kantaa siihen, koska esimerkiksi organisaatiosta poistuvien henkilöiden organisaation sisäiset käyttäjätunnukset (esim. Unix tai sähköposti) sulkeutuvat.
• Haka-infrastruktuurin tehtävä ei ole ottaa kantaa siihen, koska korkeakoulu tulkitsee että opiskelija lakkaa olemasta opiskelija (ja hänen oikeutensa opiskelijoille tarkoitettuihin resursseihin päättyy). Jonkun korkeakoulun mukaan tämä tapahtuu valmistumishetkellä, toisen korkeakoulun mukaan tämä tapahtuu kun valmistumishetkellä kulumassa oleva lukuvuosi päättyy.
• Tyypillisesti korkeakouluissa on myös lukukausi-ilmoittautumisajan päättymisen aikaan ylimenovaihe, jolloin sekä päättyvälle että alkavalle lukukaudelle ilmoittautuneet opiskelijat ovat Haka-näkökulmasta opiskelijoita.

2. Tulkinta: henkilöllisyyden todentaminen käyttäjätunnusta annettaessa

• Haka-palvelusopimus, liite 3, 2.3.2: "Antaessaan käyttäjätunnuksen uudelle loppukäyttäjälle kotiorganisaatio todentaa käyttäjätunnuksen saajan henkilöllisyyden luottamusverkoston toimintakäytäntöjen mukaisesti sekä vaatii, että käyttäjä hyväksyy ja sitoutuu noudattamaan kotiorganisaationsa käyttösääntöjä."

3. Täsmennettyjä ohjeita skeemasta

• funetEduPerson-skeeman on tarkoitus olla yhteinen nimittäjä Haka-infrastruktuurissa siirrettäville attribuuteille. Kotikorkeakoulut ja palveluntarjoajat voivat sopia myös muista attribuuteista.

4.1.Yksilöivä tunniste (eduPersonPrincipalName,EPPN)

• Käyttäjän yksilöivänä tunnisteena käytetään eduPersonPrincipalName -attribuuttia (muotoa xxxxxx@domain, esim. linden@tut.fi)
• Domain-nimenä käytetään korkeakoulun domain-nimeä
• suositus: sama korkeakoulu ei käyttä attribuutissa eri domain-nimiä, esimerkiksi yliopisto.fi ja staff.yliopisto.fi
• on kotikorkeakoulun sisäinen asia,minkä arvon domain-spesifi osa saa
• arvo voidaan ottaa esimerkiksi käyttäjätunnuksesta (esim. linden@tut.fi)
• yhdellä tosielämän henkilöllä voi olla useita EPPN-attribuutteja
• erityisesti: eri attribuutti kotikorkeakoulussa opiskelija- ja henkilökuntarooleihin (amk:ssa tyypillisesti opiskelija-työntekijällä kaksi käyttäjätunnusta)
• lisäksi: tosielämän henkilöllä, joka esimerkiksi opiskelee kahdessa korkeakoulussa, on kaksi EPPN-tunnistetta (esim. eskoesim@korkeakoulu-a.fi ja eesimerk@korkeakoulu-b.fi)
• tällöin loppukäyttäjän on kirjautuessa palveluun lähtökohtaisesti itse tiedettävä, minä näistä esiintyy
• palveluntarjoajan tulee huomioida tämän vaikutukset palvelua rakentaessaan
• henkilön EPPN-attribuutti saa vaihtua vain painavista syistä
• painava syy saattaa olla esimerkiksi avioero, jolloin sukunimen sisältävää domain-spesifiä osaa voidaan muuttaa
• jos käyttäjä haluaa profiilitietonsa säilyvän käyttämissään palveluissa, voi käyttäjä pyytää kotikorkeakouluaan ilmoittamaan EPPN-tunnisteen muuttumisesta palveluntarjoajalle
• henkilön EPPN-attribuutin kierrättäminen
• kotikorkeakoulun tulee huolehtia, että samaa EPPN-attribuutin arvoa ei anneta eri henkilölle. Kotikorkeakoulu voi harkita, antaako saman EPPN-attribuutin arvon samalle henkilölle uudelleen myöhemmin vai antaako henkilölle uuden EPPN-attribuutin arvon.
• palveluntarjoajan tulee olettaa, että EPPN:n haltijan henkilöllisyys on vaihtunut edellisen kirjautumisen jälkeen, jos hän ei ole kirjautunut järjestelmään 24 kuukauteen
• näiden toimenpiteiden on tarkoitus varmistaa, että kierrätetyn EPPN:n uusi haltija ei voi missään tapauksessa päästä käsiksi EPPN:n edellisen haltijan profiiliiin ja työtiedostoihin missään palvelimessa
• jos palvelulla on perusteltu syy säilyttää käyttäjän profiilitietoja 24 kuukautta pidempään, on funetEduPerson ver 2.0-skeemassa käytettävissä funetEduPersonEPPNTimeStamp-attribuutti

4.2. Henkilötunnus (schacPersonalUniqueID)

• korkeakoulu on voinut antaa käyttäjälle, jota ei ole kirjattu väestötietojärjestelmään, sisäiseen käyttöön tarkoitetun "keinotekoisen" henkilötunnuksen
• kotiorganisaatio ei saa asettaa keinotekoista henkilötunnusta schacPersonalUniqueID-attribuutin arvoksi
• koska mikään ei takaa, että joku toinen organisaatio ei ole antanut samaa henkilötunnusta eri henkilölle

4.3. Kotiorganisaatio (schacHomeOrganisation)

• kotiorganisaation tulee antaa jokaiselle loppukäyttäjälle sama arvo
• esim. kaikille loppukäyttäjälle joko tkk.fi tai hut.fi

4.4. Tunnistuksen varmuus (eduPersonAssurance)

Haka-liittymissopimuksen, tämän dokumentin ja REFEDS Assurance Frameworkin vaatimuksien täyttyessä kotiorganisaatiot voivat luovuttaa eduPersonAssurance attribuutin arvoina

• https://refeds.org/assurance/ID/eppn-unique-no-reassign
• https://refeds.org/assurance/ATP/ePA-1m
• https://refeds.org/assurance/IAP/high
• https://refeds.org/assurance/IAP/medium
• https://refeds.org/assurance/IAP/low
• https://refeds.org/assurance

4. Tulkinta: tietojen edelleen luovuttaminen

• Haka-liittymissopimus, kohta: "8. Palveluntarjoajan oikeudet ja velvollisuudet":
  • "ei saa käyttää saamiaan henkilötietoja muihin tarkoituksiin kuin mitä palvelua koskevassa Tietosuojailmoituksessa on määritelty."

Tulkinta:

• Haka-kirjautumisesta saatujen tietojen edelleen luovuttaminen voi tapahtua kahden Haka-palvelun välillä, kun molemmat palvelut ovat Hakan jäseniä ja ovat näin ollen Haka-sopimuksella sitoutuneet noudattamaan Haka-sopimuksen velvoitteita. Lisäksi henkilötietoa koskevaa henkilöä on informoitu tietojen luovuttamisesta ja luovutettavien tietojen käyttötarkoitus on yhteensopiva luovutuksen kohteena olevassa palvelussa.

Versiohistoria