HAKA - Helsingin yliopisto - käyttäjähallinnon kuvaus

Tässä dokumentissa ollaan kiinnostuneita käyttäjätietokannan ja sen tietojen ajantasaisuuden toteutuksen yleisistä periaatteista sellaisella tasolla, joka antaa riittävät tiedot käyttäjätietojen laadun ja ajantasaisuuden arvioimiseksi.

Kotiorganisaatio asettaa tämän dokumentin www:hen kaikkien saataville. Dokumentti linkitetään Haka-infrastruktuurin kotisivulta.

Tässä dokumentissa käyttäjätietokannalla tarkoitetaan sitä loppukäyttäjien attribuuttien joukkoa, johon organisaation Shibboleth origin tukeutuu. Käyttäjätietokannan tekninen toteutus voi olla esim. LDAP-hakemisto tai relaatiotietokanta, tai niiden yhdistelmä niin, että Shibboleth origin -palvelin hakee osan attribuuteista LDAP-hakemistosta ja osan JDBC:n yli opiskelijarekisteristä. 

1. Käyttäjätietokannan ja perusrekistereiden kytkentä

HY:llä on käynnissä uuden IAM-järjestelmän (Syncope) vaiheittainen käyttöönotto, joten yksityiskohtaiset tiedot eri järjestelmistä muuttuvat usein.

Hakaan IdP:ltä välitettävät tiedot tiedot haetaan ensijaisesti LDAP käyttäjätietokannasta, jonne ne päivitetään tietojen päälähteenä toimivasta IAM:ista. IAM:iin tietoja päivitetään sekä lähderekisteristä (Oodi, SAP HR) että suoraan järjestelmään.

1.1. Opiskelijarekisteri

Lähtöoletuksena on, että opiskelijarekisterin henkilötiedot ovat ajan tasalla.

Miten käyttäjätietokanta on kytketty opiskelijarekisteriin?

  • Opiskelijarekisterin (Oodi) ja käyttölupatietokannan (Master) välillä on tietokantalinkki molempiin suuntiin. Master-tietokantaan lisätään vähintään päivittäin uusien opiskelijoiden perustiedot ja päivitetään muuttuneet tiedot, joista läsnäolotietoja käytetään mm. käyttölupien omatoimiseen jatkamiseen ja eduPersonAffiliation -roolien määrittämiseen.
  • Master-tietokannasta muutokset päivitetään IAM:iin (Syncope) ja sieltä edelleen käyttäjätietokanta LDAP:iin. Tiedot päivitetään muuttuessa. Masterista ollaan luopumassa ja tulevaisuudessa tiedot päivitetään suoraan Oodista IAM:iin. Osan tutkintotiedoista IdP hakee LDAP:iin sijaan palveluväylän päivittämästä tietokannasta, jonne tiedot päivitetään suoraan Oodista vähintään kerran vuorokaudessa.

1.1.1. Uusi opiskelija

Miten uuden opiskelijan tiedot päivittyvät opiskelijarekisteristä käyttäjätietokantaan?

  • Uusien opiskelijoiden tiedot siirtyvät Oodista päivittäin Masteriin. Näiden perustietojen pohjalta jokaiselle generoidaan käyttäjätunnus ja sähköpostiosoite, jotka aktivoituvat ensimmäisen käyttöluvan myöntämisen yhteydessä.
  • Lupien jakelun yhteydessä tarkistetaan saajan henkilöllisyys joko vahvalla sähköisellä tunnistuksella tai henkilöllisyystodistuksesta palvelupisteellä.

1.1.2. Opiskelijan tiedoissa tapahtuu muutos

Miten opiskelijan muuttuneet tiedot päivittyvät opiskelijarekisteristä käyttäjätietokantaan?

  • Opiskelijan läsnäoloilmoittautumistiedot päivitetään Master-tietokantaan vähintään kerran vuorokaudessa.
  • Jos opiskelija ilmoittautuu läsnäolevaksi WebOodin kautta, niin läsnäolotieto päivittyy heti ja opiskelija voi myös heti jatkaa käyttölupiaan.

1.1.3. Opiskelija lakkaa olemasta opiskelija

Koska organisaatio katsoo, että opiskelija lakkaa olemasta opiskelija?

  • Opiskelijarooli päättyy, kun opinto-oikeus päättyy tai opiskelija ei ole ilmoittautunut läsnäolevaksi.

Miten tämä tieto päivittyy käyttäjätietokantaan?

  • Käyttäjähakemistossa (LDAP) pidetään yllä kustakin käyttöluvan haltijasta roolitietoa eduPersonAffiliation -sanaston mukaisesti. Jos opiskelija valmistuu, hänen opinto-oikeutensa päättyy, hän vaihtaa läsnäolonsa poissaolevaksi, keskeyttää opintonsa vuodeksi tms, poistuu häneltä "student"-rooli, vaikka käyttölupa saattaakin jäädä voimaan. Roolitieto päivittyy päivittäin.

1.2. Henkilökuntarekisteri

Vastaavasti kuin edellä.

  • Henkilökuntarekisterin (SAP HR) tiedot synkronoidaan palveluväylän kautta IAM-järjestelmään (Syncope).
    IAM-järjestelmä päivittää tiedot käyttäjätietokantaan (LDAP) tietojen muuttuessa.

1.2.1. Uusi työntekijä

  • Tiedot kirjataan SAP HR:ään, josta uuden henkilön tiedot välittyvät IAM:iin (Syncope). IAM:issa käyttäjälle luodaan käyttäjätunnus. Käyttäjätunnuksen aktivoinnin yhteydessä käyttäjä tunnistetaan joko vahvalla sähköisellä tunnistuksella tai henkilöllisyystodistuksesta palvelupisteellä.

1.2.2. Työntekijän tiedoissa tapahtuu muutos

  • Palvelussuhteen voimassaolotieto päivitetään henkilökuntarekisteristä muuttuessa palveluväylän kautta IAM:iin.
  • Nimi- yms. tiedoissa lähdejärjestelmänä toimii tunnuksen luonnin jälkeen IAM, jonne tiedot päivitetään suoraan henkilön tai Helpdeskin toimesta.

1.2.3. Työntekijä lakkaa olemasta työntekijä

  • Kun henkilöllä ei ole voimassaolevaa tointa/virkaa hoidettavana. 
  • Henkilökuntarooli päivitetään kerran vuorokaudessa (vrt. opiskelijat edellä) hakemalla roolin päivitystieto SAP HR:stä.

1.3. Muut käyttäjät ja heidän henkilötietojensa ajantasaisuus

Mille muille käyttäjille organisaatio antaa käyttäjätunnuksia (Suomen Akatemian tutkijat? Ravintolahenkilökunta? Siviilipalvelusmiehet? Dosentit? Alumnit? Emeritukset? Kirjaston asiakkaat?)

Miten heidän käyttäjätietojensa ajantasaisuus ja sulkeutuminen/roolitiedon päivittyminen on varmistettu?

  • Jos käyttäjä kuuluu esim. yllä mainittuihin erityisryhmiin, joiden tietoja ei ole opintorekisterissä tai henkilökuntarekisterissä, luodaan heille käyttäjätunnus Helpdeskin toimesta. Oikeus tunnukseen varmistetaan tällöin tunnuksen hakijan esimieheltä tai vastuuhenkilöltä. Näissä tapauksissa käyttäjän oikeudet ja tiedot, esim. affiliaatio, perustuu rooliin, jossa käyttäjä toimii yliopistossa.
  • Läsnäoleva opiskelija tai palvelusuhteessa oleva voi itse jatkaa käyttölupaansa läsnäolon tai palvelussuhteen voimassaoloajan perusteella. Opiskelija voi jatkaa lupaansa enintään läsnäoloa seuraavan lukukauden alkupuolelle eli 31.1. tai 30.9. saakka, henkilökunta joko palvelussuhteensa loppuun, mutta kuitenkin enintään puoleksitoista vuodeksi kerrallaan.
  • Roolit päivittyvät vähintään kerran yössä.

Sellaiset käyttäjät, jotka eivät ole luonnollisia henkilöitä (esim. ainejärjestöt), eivät ole myöskään Haka-infrastruktuurin tarkoittamia loppukäyttäjiä, eikä heidän kirjautumistaan shibboleth originin kautta palveluihin tule sallia.

  • Yliopiston sisäisessä käytössä on myös yleiskäyttöisiä tunnuksia ja tunnuksia joissa käyttäjän henkilöllisyyttä ei ole tunnistettu vahvasti. Nämä tunnukset voidaan tunnistaa tunnustyypin ja tunnuksen tietojen perusteella ja ne rajataan automaattisesti pois Haka-kirjautumisesta IdP:llä.

2. Henkilöllisyyden todentaminen

2.1. Käyttäjätunnuksen antamisen yhteydessä

Millä tavalla uuden käyttäjän henkilöllisyys todennetaan, kun hänelle annetaan käyttäjätunnus?

  • Vahva sähköinen tunnistus (suomi.fi) tai virallinen henkilöllisyystodistus vaaditaan.

2.2. Kun käyttäjä kirjautuu käyttäjätunnuksen avulla

Salasanatodennukseen liittyvät laatuvaatimukset.

Mahdolliset käytettävissä olevat salasanaa tukevammat autentikointimenetelmät.

  • Salasanoja koskevat kulloinkin Helsingin yliopistolla voimassa olevat laatuvaatimukset, joilla pyritään varmistamaan ettei salasana ole helposti koneellisesti arvattava tai johdettavissa henkilön tiedoista.
  • Käyttäjä voidaan tunnistaa myös Kerberos-tiketistä. Tällöin salasanatunnistus on tehty laitteelle kirjautuessa.
  • Palvelu voi vaatia käyttäjältä vahvempaa tunnistusta, jolloin käytetään Haka MFA-palvelua.

3. Käyttäjätietokannassa saatavilla olevat tiedot

Rasti kohtaan "Saatavuus", jos kyseinen henkilötieto on ajan tasalla ja siten saatavilla Shibboleth origin-palvelimen yli.

Kohtaan "Miten ajantasaisuus turvataan" esimerkiksi viittaus luvun 1. järjestelmiin.

Jos organisaatiolla on omia (ei siis funetEduPersonin mukaisia) attribuutteja, jotka näkyvät ulospäin Shibboleth originista, lisää ne taulukon loppuun. Tarvittaessa linkki dokumenttiin, joka tarkemmin kuvailee omien attribuuttien skeeman.

Attribuutti Saatavuus Miten ajantasaisuus turvataan Muuta (esim. tulkintaohje)
cn x Nimissä muuttuminen on kiinni siitä viitsivätkö nimensä muuttajat ilmoittaa muutoksista  
displayName x Nimissä muuttuminen on kiinni siitä viitsivätkö nimensä muuttajat ilmoittaa muutoksista  
eduPersonAffiliation x Vuorokausittain opiskelija- ja henkilökuntarekistereistä  Saatavilla olevat arvot: affiliate, member, student, employee, staff, faculty
eduPersonEntitlement      Muista käyttäjätiedoista IdP:llä johdettuja arvoja.  
eduPersonOrgUnitDN  x    
eduPersonPrimaryAffiliation x

Vuorokauden välein opiskelija- ja henkilökuntarekistereistä.

Saatavilla olevat arvot: affiliate, member, student, employee, staff, faculty 
eduPersonPrincipalName x Luodaan käyttäjätunnuksen pohjalta  
eduPersonScopedAffiliation x Luodaan aina Shibboleth-yhteydessä 
eduPersonAffiliation perusteella
 
employeeNumber   Vuorokausittain henkilökuntarekisteristä  
funetEduPersonEPPNTimeStamp x Tunnuksen varauksen yhteydessä, ei kierrätystä tällä hetkellä  
funetEduPersonLearnerId x Vuorokausittain opiskelijarekisteristä  
funetEduPersonProgram x Vuorokausittain opiskelijarekisteristä  
funetEduPersonSpecialisation x Vuorokausittain opiskelijarekisteristä  
funetEduPersonStudentCategory x Vuorokausittain opiskelijarekisteristä  
funetEduPersonTargetDegree x Vuorokausittain opiskelijarekisteristä  
givenname x Nimissä muuttuminen on kiinni siitä viitsivätkö nimensä muuttajat ilmoittaa muutoksista    Sisältää puhuttelunimen ja etunimien alkukirjaimet.   
logout-url x Vakioarvo  
mail x Päivitetään muuttuessa Syncope -> LDAP  
ou x Päivitetään muuttuessa Syncope -> LDAP Sisältää hallinnollisia A- ja H-koodeja ja sisältö on muuttumassa
preferredLanguage x Päivitetään muuttuessa Syncope -> LDAP  
schacDateOfBirth x Päivitetään muuttuessa Syncope -> LDAP  
schacGender x Päivitetään muuttuessa Syncope -> LDAP  
schacHomeOrganization x Vakioarvo  
schacHomeOrganizationType x Vakioarvo  
schacPersonalUniqueCode  x Päivitetään muuttuessa Syncope -> LDAP  
schacPersonalUniqueID x Päivitetään muuttuessa Syncope -> LDAP   
sn x Nimissä muuttuminen on kiinni siitä viitsivätkö nimensä muuttajat ilmoittaa muutoksista      
uid x    

4. Muuta

4.1. Kardinaliteetit

Yksi henkilöllisyys per tosielämän käyttäjä, vai

Yksi henkilöllisyys per rooli (esim. opiskelija-työntekijällä kaksi käyttäjätunnusta)?

  • Periaatteessa käyttäjällä on vain yksi tunnus, johon saatetaan liittää useita rooleja (henkilökunta, opiskelija jne). Joissakin tilanteissa käyttäjällä voi olla ns. normaalin käyttäjätunnuksen lisäksi erikoistunnuksia (ns. alaviiva- tai kevyttunnuksia), esim ylläpitokäytössä.

4.2. EduPersonPrincipalNamen revokointi ja kierrätys

Voiko eduPersonPrincipalName vaihtua?

Millä tavalla organisaatio kierrättää vapautuneita eduPersonPrincipalName-arvoja?

  • Käyttäjätunnusta ei vaihdeta, mutta käyttäjä voi luopua tunnuksestaan ja kaikista siihen liittyvistä luvistaan ja täten saada uuden. Toistaiseksi kerran käytössä ollutta käyttäjätunnusta ei oteta uudelleen käyttöön.

 

Versio Tekijä Päiväys
1.0 Ismo Aulaskari 29.7.2005
1.1 Ismo Aulaskari 24.1.2007
1.1.1. Ismo Aulaskari 15.3.2007
1.2. Jukka Karvonen 15.1.2020