Shibboleth-projekti. Tampereen teknillinen yliopisto / Digitaalisen median instituutti / Hypermedialaboratorio

Transkriptio

1 Shibboleth-projekti Tampereen teknillinen yliopisto / Digitaalisen median instituutti / Hypermedialaboratorio Käyttäjätunnistuksen pilottiprojekti Määrittelydokumentti Versionumero Päiväys Muutosperuste Tekijä Hyväksyjä Hyväksymispvm JG Rekisteröintisivun muutokset JG

2 Sisällysluettelo 1 Johdanto Yleistä projektista Shibbolethin periaate Ohjelman asentaminen Palvelinympäristö Tarvittavat ohjelmat Palvelinvarmenteet Oppimisalustan asettamat vaatimukset Käyttäjän tunnistaminen Yksilölliset tunnukset Muut sisäänkirjautumistavat Henkilötietojen hallinnan vaatimukset Auktorisoinnin vaatimukset Käyttäjähallinnon vaatimukset Henkilötietolaki Henkilötietojen käsittely Attribuuttien hyväksymismenettely Yksikäsitteisten tunnusten hallinta edupersonprincipalname (EPPN) Tunnusten kierrättäminen Tunnuksen vaihtaminen Eri tunnisteiden käyttäminen Lokitietojen säilyttäminen Tietosisällön määrittely Tietokanta Shibbolethin sovittaminen alustaan Autentikoinnin ja auktorisoinnin taso Käyttäjätietojen tallentaminen Käyttäjätietojen päivittäminen Käyttäjän roolit ja oikeudet Käyttäjätietojen sulkeminen Käyttäjänhallinnan toteuttaminen Sisäänkirjautuminen Etusivu Shibboleth-login sivu WAYF ja Origin site Käyttäjän tunnistaminen ja attribuuttien tallennus Alustakohtaisen informaation kysely Uloskirjautuminen

3 1 JOHDANTO Tämä dokumentti on määrittelydokumentti käyttäjäntunnistuksen pilottiprojektille. Dokumentissa määritellään lähtökohdat ja yleiset vaatimukset projektin toteuttamiselle. Projektin tausta, lähtökohdat sekä tavoitteet ovat määritelty jo projektisuunnitelmassa, joten tässä dokumentissa ei käsitellä kyseisiä asioita, vaan dokumentti on lähtökohdiltaan teknisempi. Dokumentissa käydään läpi teknisiä taustoja, kuten palvelinympäristö, johon projekti asetetaan sekä määritellään, mitä vaatimuksia oppimisalusta asettaa projektilta. Määrittelydokumentin toisessa kappaleessa esitellään Shibbolethkäyttäjäntunnistusmenetelmä pääpiirteissään. Kolmas kappale määrittelee asennus- ja palvelinympäristön, johon projekti toteutetaan. Neljännessä kappaleessa käsitellään oppimisalustan vaatimuksia projektille. Viidennessä kappaleessa määritellään käyttäjähallinnon asettamia vaatimuksia ja rajoituksia. Kuudes kappale määrittelee oppimisalustan tietosisällön muutoksia sekä Shibbolethin vaikutuksia tietosisällön käsittelyyn. Seitsemännessä kappaleessa käsitellään, miten käyttäjänhallinta Shibbolethin avulla pyritään toteuttamaan. 3

4 2 YLEISTÄ PROJEKTISTA 2.1 Shibbolethin periaate Tässä kappaleessa kerrotaan pääperiaatteittain Shibbolethin toiminta. Tarkempi spesifikaatio löytyy Shibbolethin kotisivuilta osoitteesta Kappaleen tarkoituksena on antaa johdanto asiaan tutustumattomalle henkilölle. Shibboleth mahdollistaa organisaatiorajat ylittävän käyttäjätunnistuksen toteuttamisen. Tähän kuuluvat seuraavat osat: henkilötietojen ylläpito, pääsynvalvonta ja käyttöoikeuksien hallinta (eli autentikointi ja auktorisointi). Shibboleth-käyttäjätunnistuksessa henkilötiedot haetaan sisäänkirjautuvan henkilön kotikorkeakoulun paikallisesta tunnushakemistosta, joten tunnusten ylläpito helpottuu. Myös henkilöllisyys todennetaan kotikorkeakoulun toimesta. Todentamisen jälkeen todennuksen tehneeltä sivustolta voidaan kysyä käyttäjään liittyviä tietoja. Näillä toimenpiteillä toteutettavan sivuston ylläpidettävyys paranee, kun sivuston ylläpitäjän ei tarvitse huolehtia tietojen päivityksestä sekä tunnusten sulkemisesta ja avaamisesta. Shibboleth koostuu lähde- ja kohdesivustosta. Korkealla tasolla määriteltynä lähdesivuston tarkoituksena on huolehtia käyttäjän tunnistamisesta, sekä käyttäjään liittyvien attribuuttien, eli käyttäjätietojen, luovuttamisesta kohdesivustolle. Kohdesivusto ottaa vastaan lähetettyjä attribuutteja, ja näiden perusteella päättää, mihin resursseihin käyttäjällä on oikeudet. Kuvassa 2.1 on esitetty Shibboleth-tunnistuksen periaate korkealla tasolla. Tärkeitä target siten asennuksessa (johon tämä projekti kohdistuu) ovat: Apachen moduuli Shire: Katsoo, onko sisäänkirjautumislippu sessiossa ja ohjaa WAYF-palveluun, jos sisäänkirjautumista ei olla toteutettu. Shar: Verkkoa kuunteleva demoni, joka pyytää origin siteltä attribuutteja annetun kahvan avulla. Apachen moduuli RM (pääsynvalvoja): Suorittaa pääsynvalvonnan Shar:n luovuttamien attribuuttien perusteella. Attribuutit tulevat näkyviin CGI-otsakkeina. 4

5 1. HTTP-pyyntö alustaan pääsemisestä WAYF 2. Mistä käyttäjä on kotoisin? A&O SHIRE 5. Tunnistaminen KORKEA- KOULU 4.Ohjaus tunnistukseen 6. Sisäänpääsypyyntö + kahva attribuutteihin 7. Tunnistetietojen kysely kahvan perusteella 8. Tunnistetietojen julkaisu sivustolle S H A R 3. Kerro kotikorkeakoulusi PÄÄSYN- VALVOJA RESURSSI Kuva 2.1: Shibboleth-tunnistuksen toiminnan periaate 5

6 3 OHJELMAN ASENTAMINEN 3.1 Palvelinympäristö Shibboleth target-site asennetaan projektissa hypermedialaboratorion palvelinkoneelle. Käytettävässä palvelimessa (ao4.ee.tut.fi) on Linux RedHat 9.3-käyttöjärjestelmä. Kääntäjän versio on GCC Tämän version kanssa on ollut ongelmia, ja kääntäjää saatetaan joutua tarvittaessa vaihtamaan, jos projektiin tarvittavaa ohjelmistoa ei saada asennetuksi nykyisillä kääntäjien versioilla. Käytössä oleva web-palvelin on Apache Shibboleth 1.1:ssa ei ole tukea tälle apachen versiolle, mutta uudessa 1.2-versiossa tämä pitäisi olla korjattu. Siten Apachea ei luultavasti tarvitse vaihtaa vanhempaan versioon. 3.2 Tarvittavat ohjelmat Shibbolethin target siten pystytykseen vaadittavia ohjelmia ovat: OpenSSL, LibCurl, Log4Cpp, Xerces-C, XMLSecurity, OpenSAML, Libapreq sekä Shibboleth target. Lisäksi palvelinkonessa tarvitaan Modssl, PHP, Expat sekä Sablotron. 3.3 Palvelinvarmenteet Kohdesivustot tarvitsevat allekirjoitetut palvelinvarmenteet, jotta lähdesivustot voivat tunnistaa pyynnön tulevan varmennetusta paikasta. Myös Kohdesivuston on lisättävä lähdesivustojen sertifikaatit omaan luotettujen palvelinten tiedostoonsa (esim. trust.xml). Federaatio vaatii usein kaupalliset palvelinvarmenteet, jotta kohde- ja lähdesivustojen oikeellisuudesta voidaan varmentua. Tämä on tapaus mm. HAKA-federaatiossa, jonka pilottivaiheessa käytetään tosin ei-kaupallisia varmenteita. 6

7 4 OPPIMISALUSTAN ASETTAMAT VAATIMUKSET 4.1 Käyttäjän tunnistaminen Yksilölliset tunnukset Koska oppimisalusta tarvitsee profiilitietoja sekä niiden säilyttämistä, on käyttäjätietoja ja tunnuksia säilytettävä tietokannassa. Siten käyttäjille on oltava sisäänkirjautumiseen tarvittava tunnus. Tunnuksen on oltava yksilöllinen, jotta sisäänkirjautuminen voidaan toteuttaa. Shibbolethin funeteduperson-skeeman attribuuteista löytyvä eduperson- PrincipalName on yksilöivä tunniste, joka koostuu käyttäjän domain-nimestä sekä domain-spesifistä osasta (ks. Kpl 5.2). Tämä tunnus on yksilöllinen, joten tunnusta voidaan käyttää oppimisalustassa käyttäjätunnuksena. Autentikointi tapahtuu origin-sitellä, ja tähän tunnistamiseen luotetaan myös target sitellä. Siten salasanaa eikä tunnusta enää kysytä target-sitellä. Käyttäjän tunnistamisen toteuttamiseen Shibbolethin avulla kerrotaan lisää kappaleessa Muut sisäänkirjautumistavat Kirjautumisen on oltava mahdollista myös muille, kuin korkeakouluille (esim. STAKES). Siten tarvitaan myös toisenlaisia sisäänkirjautumistapoja. Sisäänkirjautumistapana voidaan käyttää jo olemassa olevaa tapaa, jossa käyttäjätunnukset luodaan erikseen rekisteröitymiskaavakkeella. Kaikille käyttäjille, joilla Shibboleth-tunnistus on mahdollista, ei tämä kuitenkaan ole suotavaa, koska tällöin samalla käyttäjällä saattaa olla kahdenlaiset tunnukset toinen Shibbolethin ja toinen tavallisen rekisteröitymisen kautta. Alustan käyttäjätunnuksien luomisessa tulee estää, ettei tunnusta, joka voi olla attribuutin edupersonprincipalname-muotoinen voida ikinä luoda muuten kuin Shibboleth-tunnistuksessa. Näin estetään mahdollisten nimikonfliktien esiintyminen. Yksi mahdollisuus olisi käyttö tavallisessa sisäänkirjautumisessa. 7

8 4.1.3 Henkilötietojen hallinnan vaatimukset Oppimisalusta tarvitsee alustan toimimiseksi sekä henkilötietojen hallinnan toteuttamiseksi Shibboleth-origin siteltä seuraavia käyttäjätietoja: Yksilölinen tunniste (edupersonprincipalname) Käyttäjän etu- ja sukunimi (alusta vaatii yleisesti) (commonname) Tietyissä tapauksissa tarvitaan myös opiskelijanumero (funeteduperson- StudentId) sekä sähköposti (mail). Autentikointia käsitellään tarkemmin kappaleessa Auktorisoinnin vaatimukset Auktorisointia ei toteuteta tämän projektin puitteissa laajamittaisesti. Jos alustassa halutaan kuitenkin käyttää auktorisointin tarjoamia mahdollisuuksia, on mahdollista toteuttaa Shibboleth-tekniikan avulla useita eri auktorisoinnin tapoja ja asteita. On kuitenkin huomattava, että origin siten on luovutettava target sitelle kyseiset käyttäjätiedot, jotta auktorisointi voidaan toteuttaa. Ongelmia tämä voi aiheuttaa, jos eri origin sitet luovuttavat eri attribuutteja, tai jopa käyttävät eri skeemamäärityksiä. Federaatioon liittyminen siis kannattaa, jotta federaation sisällä voidaan sopia yhteisestä skeemamäärityksistä sekä target siteille luovutettavista attribuuteista. Suomalaiseen käyttötarkoitukseen toteutettu funeteduperson-skeema, joka hyödyntää yhdysvaltalaista eduperson-skeemaa, määrittelee seuraavia attribuutteja, joita voidaan käyttää käyttäjien valtuuttamiseen (CSC luettu ): edupersonaffiliation: Käyttäjän rooli(t) kotikorkeakoulussa. Laillisia arvoja ovat: faculty, student, staff, alum, member, affiliate ja employee. edupersonentitlement: Korkeakoulun antama valtuutus tietyn resurssin käyttöön funetedupersonhomeorganization: Käyttäjän organisaation tunniste funetedupersontargetdegreeuniversity: Korkeakoulun tavoitetutkinto 8

9 funetedupersoneducationalprogramuniv: Koulutusohjelma funetedupersonmajoruniv: Pääaine/pääaineet korkeakoulussa Lisäksi skeema määrittelee vastaavia attribuutteja ammattikorkeakouluille (esim. funetedupersontargetdegreepolytech). Attribuuttien avulla voidaan toteuttaa esimerkiksi seuraava käyttötapaus: Käyttäjä saapuu käyttämään palvelua, Shibboleth-sisäänkirjautumisen jälkeen attribuuttipyynnin (SHAR) vastaanottaa kaikki attribuutit, joita origin site julkaisee (ja target site suostuu vastaanottamaan). Attribuuteista huomataan, että edupersonaffiliation on staff, ja funetedupersonhomeorganization tut.fi. Alusta antaa käyttäjälle pääsyn ylläpidon toimenpiteisiin. Myös monimutkaisemmatkin käyttötapaukset ovat mahdollisia. Näitä ominaisuuksia ei kuitenkaan tässä dokumentissa käsitellä. 9

10 5 KÄYTTÄJÄHALLINNON VAATIMUKSET 5.1 Henkilötietolaki Henkilötietojen käsittely Henkilötieto saadaan luovuttaa Shibbolethin yli, 1. jos vastaanottajan toiminta liittyy korkeakoulun toimintaan (Henkilötietolaki 7 ), 2. jos luovutettava henkilötieto on vastaanottajan kannalta tarpeellinen (9 ), ja 3. (lähtökohtaisesti) jos henkilö on antanut siihen suostumuksen (8 ) Lisäksi henkilötietolain vaatimuksiin kuuluvat mm. yleinen suunnittelu- ja huolellisuusvelvoite, virheettömyysvaatimus sekä informointivelvoite ja tarkastusoikeus. Henkilötietolain mukaisesti siis Shibbolethilla toteutetun target siten vaatimuksiin kuuluvat seuraavat asiat: target siten on liityttävä korkeakoulun toimintaan; tietoja ei saa luovuttaa korkeakoulun ulkopuolisille tahoille; target site ei saa vastaanottaa origin siteltä tietoja, joita se ei tarvitse. Suostumus henkilötietojen luovuttamiseen kysytään origin sitellä, joten target site voi olla varma siitä, että käyttäjä hyväksyy henkilötietojen luovutuksen. Target siten on myös toteutettava henkilörekisteriseloste käsiteltävistä tiedoista helposti käyttäjän saataville Attribuuttien hyväksymismenettely Attribuuttien hyväksymismenettelyllä (Attribute Acceptance Policy, AAP) voidaan valita, mitä attribuutteja target site hyväksyy tietyltä originilta. Tämä tapahtuu käytännössä AAP.xml tiedoston konfiguroinnin avulla. Koska target site ei saa ottaa vastaan tietoja, joita se ei tarvitse, on target siten velvollisuus hyväksyä vain ne attribuutit AAP.xml tiedostossaan, joita se tarvitsee palvelun toteuttamiseen. 10

11 5.2 Yksikäsitteisten tunnusten hallinta edupersonprincipalname (EPPN) Yksikäsitteisenä tunnisteena käytetään edupersonprincipal-name tunnistetta, joka koostuu domain-nimestä ja domain-spesifisestä erotettuna (esim. Target site voi luottaa siihen, että samaan aikaan ei voi olla samaa EPPN-tunnistetta eri käyttäjien käytössä. EPPNtunnisteen käytössä voi olla kuitenkin ongelmia. Näitä ovat: domain-nimen kierrättäminen, domain-nimen vaihtaminen sekä eri tunnisteiden käyttäminen Tunnusten kierrättäminen Kun tunnus poistuu käytöstä (esim. on origin siten huolehdittava siitä, että samaa tunnusta ei oteta käyttöön 18 kk sisällä poistumishetkestä. Tämä tarkoittaa target siten kannalta sitä, että 18 kk jälkeen sama tunnus saattaa olla eri käyttäjällä. Siten target siten on huolehdittava siitä, että 18 kk käyttämättömänä olleet tunnukset poistetaan tai ne vanhentuvat siten, että saman EPPN-tunnisteen käyttö ei tuo esiin edellisen käyttäjän vanhoja käyttäjätietoja vaan luo uuden käyttäjätiedon kyseiselle tunnisteelle. 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 profiiliin ja työtiedostoihin missään palvelimessa Tunnuksen vaihtaminen Henkilön EPPN-attribuutti saa vaihtua vain painavista syistä (esim. avioero), mutta se on mahdollista. Tällöin, jos käyttäjä haluaa profiilitietonsa säilyvän, voi käyttäjä pyytää kotikorkeakouluaan ilmoittamaan target sitelle EPPN-tunnuksen vaihtamumisesta, jolloin tiedot ovat saatavilla uudella EPPN-tunnuksella. 11

12 5.2.4 Eri tunnisteiden käyttäminen Target siten on varauduttava siihen, että samalla käyttäjällä saattaa olla useampia EPPN-tunnisteita. Esimerkiksi tapauksessa, jossa henkilö opiskelee kahdessa eri korkeakoulussa, tämä on mahdollista. Target siten on huomioitava asian vaikutukset. 5.3 Lokitietojen säilyttäminen Korkeakoulun ja palveluntarjoajan (target site) on kerättävä lokia, joiden avulla pystytään yksilöimään palvelun käyttäjä, vaikka palveluntarjoaja ei normaalisti saisikaan käyttäjää yksilöivää tietoa. Target siten on kerättävä lokia, joka sisältää ainakin Shibboleth-kahvan. Lokia on säilytettävä lain määräämä aika. 12

13 6 TIETOSISÄLLÖN MÄÄRITTELY 6.1 Tietokanta Alustassa olevia käyttäjähallintaan liittyviä tauluja ovat: TAULUN NIMI hble_user hble_user_alias hble_user_authentication hble_user_settings hble_member hble_set hble_role hble_hierarchy_node hble_right KÄYTTÖTARKOITUS Käyttäjät sisältävä taulu. Käyttäjien aliakset (nimi) sisältävä taulu. Käyttäjien autentikointiin liittyvät tiedot Käyttäjien asetukset sisältävä taulu. Jäsenet, ilmoittaa mihin ryhmään käyttäjä kuuluu ja missä roolissa käyttäjä on kyseisessä ryhmässä. Eri käyttäjäryhmiä sisältävä taulu. Roolit, jotka kuuluvat tiettyyn ryhmään. Ryhmään liittyvät erikoistiedot. Oikeus resurssiin. Voi liittyä ryhmään, rooliin ja käyttäjään. Kuva 6.1 esittää oppimisalustan käyttäjätietoihin liittyviä tauluja sekä niiden keskinäisiä suhteita. Taulussa yksittäiseen käyttäjään liittyy aina tietoa autentikoinnista, kuten käyttäjätunnus ja salasana. Käyttäjään liittyy tietoa myös asetuksista. Käyttäjä on aina jäsenenä yhdessä tai useammassa joukossa. Lisäksi näissä joukoissa käyttäjä on tietyssä roolissa. Nämä sidotaan yhteen member-luokan avulla. Lisäksi oikeuksia voidaan jakaa liittyen yksittäisiin käyttäjiin, rooleihin ja joukkoihin. Jokainen joukko kuuluu yksittäiseen suurempaan osajoukkoon (hble_hierarchy_node), joka voi olla esimerkiksi yksittäinen kurssi. 13

14 hble_right hble_user_ authentication 1..* 1 hble_user 1 1..* hble_member * 0..* hble_user_alias 1..* hble_user_ settings hble_set 1 2..* hble_role 1 1 hble_ hierarchy_ node Kuva 6.1: Kaavio oppimisalustan tietokannan käyttäjätietotauluista 6.2 Shibbolethin sovittaminen alustaan Autentikoinnin ja auktorisoinnin taso Pääasiallisesti tässä projektissa keskitytään käyttäjän autentikoinnin mahdollistamiseen Shibbolethin avulla. Auktorisoinnin kaikkia mahdollisuuksia ei pyritä toteuttamaan, joskin eri vaihtoehtoja tutkitaan. Käyttäjätietojen hallintaa siis pyritään automatisoimaan Shibbolethin avulla ainoastaan kuvan 6.1 vasemmanpuoleisiin tauluihin. Käyttäjän tietoja pidetään yllä Shibbolethin avulla, mutta siihen, missä rooleissa käyttäjä on ei oteta kantaa. Auktorisointia pyritään toteuttamaan tasolla, jossa esimerkiksi tietyn organisaation käyttäjille annetaan oikeus käyttää resurssia. Esimerkki toteutettavasta auktorisoinnin tasosta on vaikkapa tapaus, jossa federaatiossa olevan korkeakoulun opiskelija pyrkii käyttämään alustaa, mutta käyttäjältä kielletään oikeus, koska target siten resurssimanageri ei ole asetettu hyväksymään sisäänkirjautumista kyseisestä organisaatiosta. 14

15 6.2.2 Käyttäjätietojen tallentaminen Kun käyttäjä hyväksytään sisäänkirjautuvaksi Shibbolethin avulla, tutkitaan vastaanotettuja attribuutteja. Tärkein tieto tässä vaiheessa on attribuutti edupersonprincipalname, joka sisältää käyttäjän yksikäsitteisen tunnisteen. EduPersonPrincipalName-attribuutti koostuu käyttäjän domain-tunnisteesta sekä domain-spesifisestä osasta (ks. kpl 5.2). Tunnusta ei saa sekottaa sähköpostiosoitteeseen, vaikka joissain tapauksissa tämä analogia toimiikin. On parempi, jos tämä tunnus ei ikinä näy käyttäjälle. Tämä tunnus toimii käyttäjän account-tunnuksena (taulussa hble_user_authentication). Tunnus sijoitetaan siis samaan paikkaan kuin tavallisessa rekisteröitymisessä asetettava käyttäjätunnus. Käyttäjätunnus on yksilöllinen, ja sattumalta saman nimen sijoittaminen estetään merkki rekisteröitymiskirjautumisessa. Tauluun asetetaan lisäksi sarake auth_type, joka sisältää käyttäjän sisäänkirjautumistavan. Shibbolethkirjautumisen yhteydessä saatavaa käyttäjätunnusta EI voida käyttää tavallisessa sisäänkirjautumisessa, vaan Shibboleth-tunnusta voi käyttää ainoastaan, kun sisäänkirjautumistapana on Shibboleth. Käyttäjän sisäänkirjautuessa Shibbolethin avulla luetaan myös muita tärkeitä attribuutteja. Tätä kirjoittaessa on vielä epäselvää, mitä attribuutteja origin site on valmis julkaisemaan, mutta ainakin seuraavia tietoja voitaisiin tallentaa: sähköposti, etunimi, sukunimi, organisaatio, koulutusohjelma, opiskelijanumero ja käyttäjän kotimaa/kieli Käyttäjätietojen päivittäminen Käyttäjän sisäänkirjautuessa Shibbolethin avulla siten, että tunnus on jo aikaisemmin olemassa, luetaan kaikki saatavat/tarvittavat attribuutit ja verrataan niitä edellisiin tietoihin. Jos tiedot ovat vaihtuneet luodaan uusi user_alias-taulun tietue, jossa on päivitetyt tiedot, ja linkitetään se käyttäjään Käyttäjän roolit ja oikeudet Shibbolethin avulla ei vielä tässä vaiheessa toteuteta käyttäjien roolien hallintaa. Roolit asetetaan siis ylläpitäjän toimesta käsin. Jos origin siteltä saadaan 15

16 esimerkiksi tietoja siitä, mille kursseille opiskelija on ilmoittautunut tai millä kursseilla opettaja on vastuuhenkilönä, voitaisiin jatkossa asettaa rooleja suoraan kurssinumeroiden perusteella. Tätä ei siis toteuteta vielä tämän projektin yhteydessä Käyttäjätietojen sulkeminen Oppimisalustassa käyttäjien tietoja ei poisteta. Tämä aiheuttaa kuitenkin ongelman yksikäsitteisten tunnusten osalta, sillä kaikki yli 18 kuukautta poistuneena olleet yksikäsitteiset tunnukset (edupersonprincipalname) voidaan ottaa uudestaan käyttöön. Jos tällöin oppimisalustassa on sama yksikäsitteinen tunnus, jota ei ole poistettu, saattaa uusi käyttäjä päästä toisen henkilön yksityisiin tietoihin käsiksi. Siksi ongelma pitää ratkaista muuttamalla jollakin tavalla vanhentuneiden käyttäjien account-tunnusta. 16

17 7 KÄYTTÄJÄNHALLINNAN TOTEUTTAMINEN 7.1 Sisäänkirjautuminen Etusivu Oppimisalustan etusivulla näytetään sisäänkirjaankirjautumiseen liittyvät tiedot. Koska sisäänkirjautumiseen tarvitaan myös toinen tapa (ks. kpl ), on etusivulla oltava mahdollisuus kahteen eri sisäänkirjautumistapaan. Eri tapojen eroavaisuudet on tehtävä selkeiksi, ja olisi parempi, jos esim. termiä Shibbolethkirjautuminen ei käytettäisi, vaan selkeyden vuoksi korvattaisiin se vaikkapa termillä Kirjautuminen korkeakoulun tunnuksilla. Jos käyttäjä haluaa kirjautua korkeakoulun tunnuksilla, on käyttäjän painettava kyseistä linkkiä, joka ohjaa käyttäjän Shibboleth-login -sivulle Shibboleth-login sivu Shibboleth-login sivu ei näy käyttäjälle, vaan sen tarkoituksena on toimia proxyna käyttäjän sisäänkirjautumiselle Shibbolethin välityksellä. Käytännössä sivu on shibbolethin avulla suojattu käyttäjäntunnistus- ja attribuuttientallennussivu. Koska sivu on suojattu Shibbolethin avulla, se ohjaa käyttäjän WAYF-palveluun, jos käyttäjää ei ole vielä tunnistettu. Tämä tapahtuu apachen konfiguraatioista asettaamalla Location-direktiiviin AuthType shibboleth. Apachen location-direktiivin sisään voidaan asetettaa myös vaatimuksia ja rajoitteita sisäänpääsylle. Samaa (ja monipuolisempaa) pääsynvalvontaa voidaan toteuttaa myös palvelun sisällä ennen sisäänkirjautumista WAYF ja Origin site WAYF, eli Where Are You From?, palvelun tehtävänä on antaa käyttäjän valita, minkä kotikorkeakoulun sisäänkirjautumista käytetään. Luonnollisesti käyttäjä valitsee oman kotikorkeakoulunsa, jonne käyttäjä tämän jälkeen ohjataan. Käyttäjä sisäänkirjautuu origin sitellä, joka lähettää kahvan target 17

18 sitelle. Target site käyttää kahvaa attribuuttien kyselemiseen, joiden perusteella tehdään päätös jatkotoimenpiteistä Käyttäjän tunnistaminen ja attribuuttien tallennus Käytännössä sisäänkirjautumishetkellä on kolme eri vaihtoehtoa. Seuraava tilakaavio esittää sivuston toimintaa sisäänkirjautumisvaiheissa, kun muuttujina ovat tiedot siitä, onko käyttäjä tunnettu (aikaisemmin sisäänkirjautunut) tai jo valmiiksi sisällä. KÄYTTÄJÄ SISÄLLÄ ei ei - rekisteröidy - aktivoi istunto - siirry sivulle KÄYTTÄJÄ TUNNETTU kyllä - aktivoi istunto - päivitä tiedot - siirry sivulle kyllä (mahdoton) - siirry sivulle Jos käyttäjä ei ole tunnettu ja ei ole vielä sisällä, ohjataan käyttäjä erilliselle rekisteröitymissivulle, jossa kysytään tietoja, joita ei saada origin siteltä (ks. Kpl 7.1.5, alustakohtaisen informaation kysely). Kun tämä rekisteröityminen on tehty, aktivoidaan istunto, eli kirjataan käyttäjä sisään oppimisalustaan. Jos käyttäjä on jo aikaisemmin tunnettu, aktivoidaan istunto, päivitetään attribuuteista saadut muuttuneet tiedot tietokantaan ja siirrytään sivulle. Jos käyttäjä on jo sisäänkirjautunut, ohjataan käyttäjä suoraan sivulle tekemättä muita toimenpiteitä. Shibbolethin käyttämä eväste poistetaan heti kun attribuutit ovat näkyviä ja saatu tallennettua. Jos käyttäjä ei ole rekisteröitynyt, talletetaan HTTP-otsakkeina näkyvät attribuutit istuntoon ja ohjataan käyttäjä rekisteröitymispalveluun. Rekisteröitymispalvelu ei ole shibbolethin avulla suojattu, joten evästeen poistaminen ei vaikuta rekisteröitymispalvelun toimintaan Alustakohtaisen informaation kysely Alustakohtaista informaatiota ovat tiedot, joita ei saada origin siteltä. Tällainen tieto voisi vaikkapa olla lempinimi, jolla käyttäjä tunnetaan oppimisalustalla. 18

19 Koko sisäänkirjautumistapahtumaa kuvaa alla oleva kaavio 7.1: TARGET SITE ORIGIN SITE ETUSIVU kirjaudu ISTUNNON ALOITUS REKISTERÖITYMINEN Käyttäjä olemassa, tiedot päivitetään Shibboleth-istunto poistetaan Uusi käyttäjä SHIBLOGIN Suojattu shibbolethilla. Sisältää kirjautumispalveun. KIRJAUTUMIS PALVELU Tarkastaa, voidaanko käyttäjä ottaa sisään, onko käyttäjällä jo tiliä ja käyttäjä jo sisällä. TUNNISTUS Kuva 7.1 Sisäänkirjaantuminen ohjelman tasolla 7.2 Uloskirjautuminen Uloskirjautuminen toteutetaan samalla tavalla, kuin alustassa on jo toteutettu. Alusta kirjaa käyttäjän uloskirjautuneeksi, eikä istuntotunnistetta enää voida käyttää. Alusta ei ota kantaa siihen, miten käyttäjä kirjautuu ulos korkeakoulun järjestelmästä, johon käyttäjä on sisäänkirjautunut. Shibboleth-eväste on poistettu jo sisäänkirjautumisvaiheessa. 19