Haka-infrastruktuuri

Kotiorganisaation käyttäjähallinnon kuvaus

Versio

Tekijä

Päiväys

  0.1

  Jarmo Kauppinen

  27.5.2008

  0.2

Jarmo Kauppinen

  12.8.2008

0.3

Jarmo Kauppinen

2.1.2009

1.0

Jarmo Kauppinen

19.1.2009

2.0

Jarmo Kauppinen

25.4.2018

3.0

Jarmo Kauppinen

9.4.2019

 

 

 

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 ja päivitettävä oma-aloitteisesti, kun muutoksia tulee. Dokumentti linkitetään Haka-infrastruktuurin kotisivulta.

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

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

1.1. Opiskelijarekisteri

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

Peppi-perusrekisterin tietojen ajantasaisuudesta vastaa Centrian opintohallinto ja viime kädessä opintoasianpäällikkö.

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

Centria ammattikorkeakoulun käyttäjätietokantana, johon Identity Provider tukeutuu, pidetään Metahakemistoa. Metahakemisto on yhteydessä Centria ammattikorkeakoulun opintohallinnon Peppi -perusrekisteriin seuraavalla tavalla: Integraatio -tuote ja sen ajurit välittävät käyttäjien tietoja Pepistä rajapinnan kautta kerran vuorokaudessa metahakemistoon.

Centria ammattikorkeakoulussa on käytössä Active Directory ja tietokoneille kirjautumisiin käytetään autentikointihakemistona Active Directoryä. Integraatiotuotteen ajurit synkronoivat tietoja Active Directoryn ja Metahakemiston välillä, käyttäjiä sisältävä metahakemisto on identtinen Active Directoryn kanssa.

 

1.1.1. Uusi opiskelija

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

 

Opiskelijan tullessa valituksi Centria ammattikorkeakouluun hänen tietonsa noudetaan OILI järjestelmästä tai syötetään Peppi perusrekisteriin. Seuraavana yönä ajetaan rekisteristä kaikkien ammattikorkeakoulun opiskelijoiden uudet tai muokatut tiedot metahakemistoon. Integraatiotuotteen ajurit reagoivat muutoksiin. Tiedot välitetään Metahakemistoon, josta ne edelleen synkronoidaan Active Directoryyn.


Koska uusi opiskelija saa käyttäjätunnuksen/opiskelijaroolin?

 

Uuden käyttäjän tietojen siirron yhteydessä generoidaan myös käyttäjätunnus, salasana, sähköpostiosoite ja opiskelija liitetään opiskelijarekisterin tietojen perusteella saapumisryhmänsä mukaiseen käyttäjä/postituslistaan sekä opetusyksikkönsä mukaiseen postituslistaan. Lisäksi kaikki opiskelijat liitetään yhteiseen postituslistaan. Käytännössä seuraavana päivänä siitä päivästä, kun opiskelijan tiedot on syötetty opiskelijarekisteriin, on opiskelijalla valmiina käyttäjätunnus, salasana, sähköpostiosoite ja hänet on liitetty käyttäjäryhmiin ja postituslistoille, joihin hän yksikkönsä ja saapumisryhmänsä mukaan kuuluu. Roolina tämän jälkeen hakemistoissa hänellä on opiskelija.

 

Käyttäjätunnuksen opiskelija saa käyttöön opetusyksikkönsä kautta, kun hän aloittaa opiskelun. Yksiköiden käytössä on sisäverkossa suojattu sivusto, jonka kautta yksikön HelpDesk-tuki ja opintotoimisto saavat uusien opiskelijoiden käyttäjätunnukset ja salasanat listattua saapumisryhmittäin. Käyttäjätunnusten jakamisen yksikössä suorittaa joko HelpDesk-tuki tai opintotoimisto sen mukaan, miten kussakin opetusyksikössä on sovittu.


Mitä tunnukselle tapahtuu, jos uusi opiskelija ei ota opiskelupaikkaa vastaan, tai ottaa paikan vastaan mutta ilmoittautuu poissaolevaksi?

 

Opiskelijarekisteriin tehdään merkintä opiskelijan läsnäolon muutoksesta, läsnäolon muutos välittyy rajapinnan avulla integraatiotuotteelle ja tähän muutokseen integraatiotuotteen ajurit reagoivat, ajureihin on koodattu, mitä tehdä tunnukselle, kun läsnäolotieto muuttuu, eri läsnäolokoodeille on omat toimintonsa ajureissa.

Tapauksissa joissa opiskelupaikkaa ei oteta vastaan, aiheuttaa opiskelijarekisterissa tehdyn muutoksen jälkeen sen, että seuraavana päivänäopiskelija, ei pääse kirjautumaan järjestelmiin, sillä tunnus lukitaan hakemistoissa ja siirretään erilliseen OU:hun hakemistoissa, josta yksiköiden tukihenkilöt käyvät tunnuksia manuaalisesti poistamassa.

IT tukihenkilön vastuulla on siivota yksikkönsä poistetut tunnukset hakemistosta. Tukihenkilöt siivoavat tunnukset Active Directoryn kautta, josta tieto välittyy metahakemistoon, muutos välitetään integraatiotuotteen avulla kaikkiin järjestelmiin.

 

Läsnäolotiedon muuttuessa poissaolevaksi tunnus lukkiutuu ja siirtyy hakemistohaaraan jossa disabloidut tunnukset, säilyvät niin kauan, että läsnäolotieto muuttuu, jolloin tunnuksesta tehdään jälleen aktiivinen ja se siirtyy automaattisesti oman roolinsa ja yksikkönsä mukaiseen paikkaan hakemistossa tai se voidaan siirtää myös OU haaraan, johon siirrettävään poistettavat tunnukset, mikäli muuttunut läsnäolotieto sitä edellyttää.

 

1.1.2. Opiskelijan tiedoissa tapahtuu muutos

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

 

Aikaisemmin kuvatuilla tavoilla eli opiskelijarekisteriin tehty muutos näkyy muutoksena opiskelijarekisteristä rajapinnan välittäessä tietoja. Integraatiotuotteen ajurit reagoivat muutoksiin ja välittävät tiedot metahakemistoon, josta tieto synkronoidaan Active Directoryyn ja muihin järjestelmiin.

1.1.3. Opiskelija lakkaa olemasta opiskelija

Koska organisaatio (esim. opintoasiainhallinto) katsoo, että opiskelija lakkaa olemasta opiskelija
a) sen jälkeen kun opiskelija valmistuu?
b) sen jälkeen kun lukukausi vaihtuu, ja opiskelija ei ole ilmoittautunut läsnäolevaksi?
c) sen jälkeen kun opiskelija ilmoittaa keskeyttävänsä opinnot?

Kuinka kauan ylläolevien tapahtumien jälkeen kestää, että organisaatio (esim. tietohallinto) sulkee opiskelijan käyttäjätunnuksen tai poistaa opiskelijaroolin?

 

Käyttäjätunnus automatiikka reagoi muutoksiin kerran vuorokaudessa eli tunnukset lukkiutuvat päivän viiveellä opiskelijarekisterissa tehtyihin muutoksiin kohdat a, b ja c. Tunnukset poistetaan manuaalisesti yksiköiden IT-tukihenkilöiden toimesta.

1.2. Henkilökuntarekisteri

Käyttäjähakemiston primäärinätietolähteenä henkilökunnan osalta pidetään Centria ammattikorkeakoulussa henkilöstöhallinnon järjestelmää. Kaikkien henkilökuntaan kuuluvien tietoja säilytetään ja päivitetään henkilöstöhallinnon järjestelmässä.

Henkilökuntarekisterin päivittäminen on henkilöstöhallinnon vastuulla.

1.2.1. Uusi työntekijä

Uuden työntekijän tullessa taloon, hänen tietonsa ilmoitetaan henkilöstöhallinnolle. Ilmoitus uuden henkilön lisäämisestä tulee automaattisesti IT-osastolle integraatiotuotteen välittämänä.

Henkilöstöhallinnon kirjaamat henkilön tiedot välittyvät kerran vuorokaudessa integraatiotuotteen avulla hakemistoihin.

Automatiikka luo aivan kuten opiskelijallekin, uudelle työntekijälle käyttäjätunnuksen, salasanan, sähköpostin ja liittää hänet yksikkönsä ja roolinsa mukaisiin ryhmiin hakemistoissa.

Tunnuksen työntekijä saa käyttöön seuraavana päivänä ja sen jakaa hänelle IT-tuki..

1.2.2. Työntekijän tiedoissa tapahtuu muutos

Tiedot päivitetään kerran vuorokaudessa käyttäjähakemistoon.

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

Henkilöstöhallinto merkkaa henkilöstöhallinnon tietojärjestelmään, kun henkilön työsuhde päättyy. Rekisteriin tehtyjen tietojen perusteella tunnus lukitaan työsuhteen päättymisestä seuraavana yönä ja tunnus poistetaan manuaalisesti IT-tuen toimesta.

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

Onko organisaatiossa vielä jotain muita käyttäjiä, joilla on käyttäjätunnus ja jotka voivat kirjautua Identity Provider -palvelimen kautta Haka-infrastruktuurin palveluihin (Suomen Akatemian tutkijat? Ravintolahenkilökunta? Siviilipalvelusmiehet? Dosentit? Alumnit? Emeritukset? Kirjaston asiakkaat?). Minkälainen haku- ja hyväksymismenettely näihin tunnuksiin liittyy?
Miten heidän käyttäjätietojensa ajantasaisuus ja sulkeutuminen/roolitiedon päivittyminen on varmistettu?

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 Identity Provider -palvelimen kautta palveluihin tule sallia.

Käyttäjätunnukset, joiden tiedot välitetään metahakemisto palvelimelle ovat ainoastaan Centrian tutkinto-opiskelijoille ja henkilökunnalle. Muiden käyttäjien tunnukset luodaan käyttäjähakemistossa sellaisiin haaroihin, joista tietoja ei välitetä metahakemistolle, näitä tunnuksia hallitaan manuaalisesti ja pääsy on vain Centrian paikallisiin järjestelmiin.

 

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?

 

Henkiöllisyys todennetaan viranomaisen hyväksymällä, kuvallisella henkilöodistuksella tunnuksen luovuttamisen ja salasanan palauttamisen yhteydessä.

 

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

Salasanatodennukseen liittyvät laatuvaatimukset.

 

Salasanat pakotetaan vaihtamaan kerran lukukauden aikana.

Salasanan pitää täyttää ehto:


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

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

Lisätietoja funetEduPerson-skeemasta (ver 2.0) on täällä.

Rasti kohtaan "Saatavuus", jos kyseinen henkilötieto on ajantasalla ja siten saatavilla Identity Provider -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 Identity Provider-palvelimesta, lisätään ne taulukon loppuun. Tarvittaessa linkki dokumenttiin, joka tarkemmin kuvailee omien attribuuttien skeeman.

Attribuutti

Saatavuus

Miten ajantasaisuus turvataan

Muuta (esim. tulkintaohje)

cn / commonName

  x

  peppi,personec

 MUST

description

 

 

 

displayName

  x

  peppi,personec

 MUST

employeeNumber

  x

  personec

 

facsimileTelephoneNumber

 

 

 

givenName

  x

  peppi,personec

 

homePhone

 

 

 

homePostalAddress

 

 

 

jpegPhoto

 

 

 

l / localityName

  x

  vakio

 

labeledURI

 

 

 

mail

x

  ldap

 

mobile

 

 

 

o / organizationName

  x

 vakio

 

ou / organizationalUnitName

 

 

 

postalAddress

 

 

 

postalCode

  x

 

preferredLanguage

  x

  peppi

 

seeAlso

 

 

 

sn / surname

  x

  peppi, personec

 MUST

street

 

 

 

telephoneNumber

 

 

title

 

 

 

uid

 

 

 

userCertificate

 

 

 

eduPersonAffiliation

  x

  peppi,personec

 Staff, student

eduPersonEntitlement

 

 

 

eduPersonNickName

 

 

 

eduPersonOrgDN

 

 

 

eduPersonOrgUnitDN

 

 

 

eduPersonPrimaryAffiliation

 

 

 

eduPersonPrimaryOrgUnitDN

 

 

 

eduPersonPrincipalName

  x

  Arvo generoidaan tunnuksen luonnin yhteydessä, opiskelijalla c+opiskelijanumero@cou.fi eli esimerkiksi co123456@cou.fi henkilökuntaan kuuluvalla h+henkilökuntanumero@cou.fi eli esimerkiksi h123456@cou.fi , eduPersonPrincipalName arvo on uniikki

 MUST

eduPersonScopedAddiliation

 

 

 

eduPersonTargetedID

 

 

 

schacMotherTongue

 

 

 

schacGender

 

 

 

schacDateOfBirth

 

 

 

schacPlaceOfBirth

 

 

 

schacCountryOfCitizenship

 

 

 

schacHomeOrganization

  x

 cou.fi

MUST.

schacHomeOrganizationType

  x

urn:mace:terena.org:schac:homeOrganizationType:fi:polytechnic

MUST

schacCountryOfResidence

 

 

 

schacUserPresenceID

 

 

 

schacPersonalUniqueCode

 

 

 

schacPersonalUniqueID

 

 

 

schacUserStatus

 

 

 

funetEduPersonHomeOrganization

 

 

superseded

funetEduPersonStudentID

x

peppi

superseded

funetEduPersonIdentityCode

 

 

superseded

funetEduPersonDateOfBirth

 

 

superseded

funetEduPersonTargetDegreeUniversity

 

 

superseded

funetEduPersonTargetDegreePolytech

 

 

superseded

funetEduPersonTargetDegree

 

 

 

funetEduPersonEducationalProgramUniv

 

 

superseded

funetEduPersonProgram

x

winha

superseded

funetEduPersonProgram

 

 

 

funetEduPersonMajorUniv

 

 

superseded

funetEduPersonOrientationAlternPolytech

 

 

superseded

funetEduPersonSpecialisation

 

 

 

funetEduPersonStudyStart

 

 

 

funetEduPersonPrimaryStudyStart

 

 

 

funetEduPersonStudyToEnd

 

 

 

funetEduPersonPrimaryStudyToEnd

 

 

 

funetEduPersonCreditUnits

 

 

 

funetEduPersonECTS

 

 

 

funetEduPersonStudentCategory

 

 

 

funetEduPersonStudentStatus

 

 

 

funetEduPersonStudentUnion

 

 

 

funetEduPersonHomeCity

 

 

 

funetEduPersonEPPNTimeStamp

 

 

 

 

 

 

 

 

 

 

 

4. Muuta

4.1. Kardinaliteetit

Yksi henkilöllisyys per rooli.

4.2. EduPersonPrincipalNamen revokointi ja kierrätys

 

Voiko eduPersonPrincipalName vaihtua?

Voi, jos syy on perusteltu, mutta lähtökohtaisesti arvo on uniikki. Opiskelijoilla arvo muodostuu opiskelijanumeron perusteella ja toista samanlaista arvoa ei voi tulla, joten opiskelijoille muutosta ei tule, tosin henkilön jokaiselle roolille luodaan oma tunnus. Henkilökuntaan kuuluvalla nimen muutoksen yhteydessä tunnusta voidaan muuttaa, lähtökohtaisesti näin ei kuitenkaan tehdä, vain perustellusta syystä.

 

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

 

Tunnukset poistetaan lopullisesti IT-henkilöstön toimesta manuaalisesti. IT-henkilöstöä on ohjeistettu toimimaan niin, että tunnuksen saa poistaa vasta, kun poistettavan tunnuksen lukkiutumisesta on kulunut kauemman kuin 24kk. Uniikki opiskelijanumero ja uniikki henkilökunnan henkilökuntanumerovarmistavat sen, että kahta samanlaista ePPn arvoa ei voi tulla.