Rooli vai ryhmä? Miten rajaan pääsyä sovellukseen?
Sovelluksen käyttöä halutaan usein rajata niin, että vain tietty käyttäjäjoukko pääsee kirjautumaan sisään sovellukseen tai osalle käyttäjäjoukosta halutaan laajemmat valtuudet kuin muille. Tätä rajaamista kutsutaan valtuuttamiseksi eli auktorisoinniksi (authorization). Esimerkiksi sovellukseen saa kirjautua sisään kaikki yliopiston työntekijät ja opiskelijat, mutta vain pieni erikseen nimetty joukko saa muokata sovelluksessa olevia tietoja.
Jokainen sovellus on yksilöllinen, joten sovelluksen yksilölliset tarpeet on hyvä miettiä ja sovelluksen käyttäjäryhmät kuvata. Usein kuitenkin huomataan, että tietyt käyttäjäryhmät toistuvat ja samoja käyttäjäryhmiä tarvitaan monissa eri sovelluksissa. Siksi kannattaakin pysähtyä hetkeksi pohtimaan voitaisiinko sovellukseen pääsyä rajata jollain jo olemassaolevalla tavalla. Näin ratkaisusta syntyy käyttäjillekin selkeämpi kokonaisuus.
Suositellut tavat käyttäjien valtuuttamiseen
Alla on kuvattu erilaisia ratkaisuvaihtoehtoja käyttäjien valtuuttamiseen. On hyvä huomata, että usein sovelluksessa voidaan käyttää useampaa erilaista tapaa yhtäaikaa. Esimerkiksi suurin käyttäjäoukko hoidetaan keskitetysti ylläpidetyillä attribuuteilla ja pienempi käyttäjäoukko IAM-ryhmällä. Vaihtoehdot eivät ole toisensa poissulkevia. Myöskin kaikkia valtuuttamisen vaihtoehtoja voidaan käyttää kaikkien eri tunnistusvaihtoehtojen kanssa.
1) Valmiit keskitetysti ylläpidetyt attribuutit
Tämä on suositelluin ja käyttäjien kannalta selkein vaihtoehto. Ylivoimaisesti tyypillisin tapa on käyttää eduPersonAffiliation-attribuuttia eli käyttäjän roolitietoa mikä on määritelty yhteiseksi kotimaisten korkeakoulujen kanssa eli toimii tarvittaessa myös Haka-kirjautumisessa muiden korkeakoulujen käyttäjille.
eduPersonAffiliation-attribuutin vaihtoehdot ovat:
- student = läsnäolevat opiskelijat
- faculty = opetus- ja tutkimushenkilökunta
- staff = muu henkilökunta
- employee = kaikki yliopiston työntekijät = faculty + staff
- member = student + employee + mahdollisesti joitakin erillisiä opintoja suorittavat opiskelijat
- affiliate = kaikki loput käyttäjät eli ne joilla ei ole member-roolia. Sisältää mm. vierailijat, ei-läsnäolevat opiskelijat ja Avoimen yliopiston opiskelijat.
Myös opiskelijan kategoriaa eli funetEduPersonStudentCategory attribuuttia tai organisaatioyksikkö tietoa käytetään jonkin verran.
Katso kaikki attribuutit sivulta Shibboleth käyttäjäattribuutit tai LDAP2015 käyttäjäattribuutit.
Huom. SP-rekisterin attribuutti-tietoihin olisi hyvä dokumentoida, jos kyseistä attribuuttia käytetään pääsyn rajoittamiseen.
2) IAM-ryhmät
Toinen suositeltu vaihtoehto käyttäjien valtuuttamiseen on IAM-ryhmät. Yleisimpiä käyttötapauksia varten on luotu valmiiksi hy-alkuisia ryhmiä, joiden jäsenlista ylläpidetään keskitetysti esim. SAP HR:n tietojen perusteella. Jos valmiista ryhmistä ei löydy sopivaa ryhmää sovelluksen käyttötapasta varten, voi kuka tahansa yliopistolainen luoda uuden ryhmän. Ryhmien käyttö on sikäli kätevää, että niitä voidaan käyttää myös sähköpostilistoina ja muissa sovelluksissa. Käyttäjän ei tarvitse myöskään mitenkään hakea ryhmän jäsenyyttä vaan ryhmän omistaja voi lisätä ryhmään vapaasti jäseniä (myös määräajaksi).
Esimerkiksi seuraavat ryhmät ovat todennäköisesti hyödyllisiä:
1) hy-tiedekuntalyhenne-osastolyhenne-employees ja hy-erillislaitoslyhenne-employees
- Sisältävät kyseisen organisaatioyksikön työntekijät, joilla on SAP-HR:ssä voimassa oleva työsopimus eivätkä ole työstä vapautettuina.
2) hy-tiedekuntalyhenne-osastolyhenne-supervisors ja hy-erillislaitoslyhenne-supervisors
- Sisältävät kyseisen organisaatioyksikön työntekijät, joilla on SAP-HR:ssä voimassa oleva työsopimus ja esimiehen status (eivätkä ole työstä vapautettuina).
3) hy-tiedekuntalyhenne-osastolyhenne-teach-research ja hy-erillislaitoslyhenne- teach-research
- Sisältävät kyseisen organisaatioyksikön työntekijät, joilla on SAP-HR:ssä voimassa oleva työsopimus, kuuluvat opetus- ja tutkimushenkilöstöön (uraportailla 1-4) eivätkä ole työstä vapautettuina.
4) hy-tiedekuntalyhenne-osastolyhenne-coemployees ja hy-erillislaitoslyhenne-coemployees
- Sisältävät kyseisen organisaatioyksikön emeritusprofessorit, vierailevat tutkijat, dosentit joilla dosenttisopimus, apurahatutkijat, vierailevat professorit, joilla on HY:n käyttäjätunnus ja SAP-HR:ssä voimassa olevat sopimustiedot (muu kuin työsopimus, henkilöstöalaryhmä D2-D6).
5) hy-tiedekuntalyhenne-osastolyhenne-allstaff ja hy-erillislaitoslyhenne-allstaff
- Sisältävät vastaavan -employees ja -coemployees -loppuisen ryhmän + mahdollisesti käsin lisättyjä henkilöitä, joiden tiedot eivät tule SAP HR:stä.
- Palvelukoordinaattorit päivittävät näitä ryhmiä.
6) hy-employees
- Sisältää kaikki yliopiston työntekijät, joilla on SAP-HR:ssä voimassa oleva työsopimus. Myös työstävapautetut ovat mukana. HUOM: Tätä ei voi käyttää sähköpostilistana.
Katso myös Suosituksia IAM-ryhmien käytöstä ja IAM-ryhmienhallintatyökalun käyttöohjeet. IAM-ryhmienhallintatyökalussa voit esim. etsiä muiden tekemiä ryhmiä.
Huom. Jos luot itse ryhmän, muista lisätä itsesi ryhmän jäseneksi, jotta tieto päivittyy omiin käyttäjätietoihisi.
IAM-ryhmät löytyvät keskitetyn tunnistuksen kautta seuraavista käyttäjän attribuuteista:
- Shibboleth (SAML2 / OIDC): hyGroupCn
- LDAP2015: memberOf
3) Hero-roolit
Mikäli sovelluksen käyttövaltuuksien hallintaan halutaan monivaiheisempi prosessi/hyväksymisketju, voidaan käyttää Hero-järjestelmän kautta haettavia rooleja. Herossa henkilö ensin itse hakee sovelluksen käyttövaltuutta, sen jälkeen henkilön esimies hyväksyy tai hylkää hakemuksen ja tämän jälkeen sovelluksen pääkäyttäjä vielä hyväksyy tai hylkää hakemuksen. Tämän jälkeen käyttövaltuus (yleensä automaatisesti) viedään sovellukseen. Rajapinta sovitaan erikseen kunkin sovelluksen kohdalla. Heron-rooleista voidaan myös luoda automaattisesti IAM-ryhmiä, jolloin ne pystytään sovelluksessa lukemaan samasta attribuutista kuin IAM-ryhmät.
Lisätietoja Herosta löytyy Helpdeskin ohjeista.
4) IAM-roolit (pilottikäytössä)
IAM-roolienhallintasovellus on tällä hetkellä pilottikäytössä. Sinne on määritelty muutama rooli ja sovellus joita se hallinnoi, mutta käyttö on vielä vähäistä. Kunhan sovellusta ehditään hiljalleen kehittämään sen on tarkoitus korvata Hero asteittain.
5) Sovelluksen sisäinen käyttövaltuuksienhallinta
Sovellukseen pääsyä voidaan rajoittaa myös sovelluksen sisäisellä käyttävaltuushallinnalla, mutta tämä ei ole suositeltavaa, mikäli jokin yllä mainituista vaihtoehdoista vain on mahdollinen. Yliopiston IAM-periaatteiden mukaisesti yliopistilla pitäisi olla jossain keskitetyssä paikassa tieto mihin kullakin käyttäjällä on pääsy ja tätä tavoitetta on mahdoton toteutta, mikäli käytetään ainoastaan sovelluksen sisäistä käyttövaltuushallintaa.