FAQ
Liittyminen ja rekisteröinti
Asiakkaamme haluaisi Haka-kirjautumisen palveluun mahdollisimman nopeasti, mutta liittymisprosessi on kesken. Miten sitä voisi nopeuttaa?
Ohjausryhmä hyväksyy Haka-kumppanit ja tämän lisäksi palvelusopimuksen allekirjoituskierrossa CSC:llä kuluu aikaa. Tätä prosessia ei voi nopeuttaa, vaan projektissa siihen kannattaa varata kalenteriaikaa 4-6 viikkoa (yleensä sopimiskierto on kuitenkin valmis jo muutamassa viikossa). Liittymisprosessi on kuvattu omalla sivullaan.
Samanaikaisesti sopimusprosessin edetessä Haka-kirjautumisen käyttöönottoa voi edistää teknisesti toteuttamalla ja testaamalla palvelun Haka-integraatio valmiiksi. Kaikki Hakaan liitettävät entiteetit testataan ennen tuotantometadataan lisäämistä vasten operaattorin testipalvelimia. Operaattori varmistaa, että entiteetti on toteuttanut onnistuneen kirjautumisen vasten testipalvelinta ennen tuotantometadataan siirtämistä.
Testaamisen lisäksi palvelun siirtämiseksi Hakaan tarvitaan myös vahvistus kumppanin tai jäsenen hallinnolliselta yhteyshenkilöltä. Valmistele yhteyshenkilö jo etukäteen, että hän arvioi vastuulleen kuuluvat asiat ajoissa ennen tuotantoon siirtymistä:
Luottamusverkoston jäsenen tai kumppanin hallinnollinen yhteyshenkilö varmistaa erityisesti, että
- palvelu ei ole ristiriidassa luottamusverkoston toiminnan tarkoituksen kanssa (Liite 2: ”Haka-luottamusverkoston toiminnan tarkoitus on tukea korkeakoulujen ja tutkimuslaitosten toimintaa”)
- hakemuksessa esitetyt henkilötiedot, joita palvelu katsoo tarvitsevansa loppukyttäjistä, ovat palvelun tuottamisen kannalta tarpeellisia (Henkilötietolaki 9 §)
- Haka-palvelusopimus, liite 3, kohta 4 SAML-palvelun rekisteröiminen luottamusverkostoon
SAML-tekniikaan hyvin perehtynyt IT-asiantuntija toteuttaa teknisesti federoinnin muutaman kalenteriviikon kuluessa. Laajasti käytettyjä SAML-tuotteita, kuten Shibbolethia käytettäessä tekninen käyttöönotto voidaan tehdä muutamassa päivässä. Sovelluksen autentikaation ja sessionhallinnan toteutuksesta riippuu, miten helppoa sen federointi on. Projektin aikataulutuksessa on myös huomioitava muut ennakoivat työvaiheet, kuten tuotevalinta, henkilötietojen käsittelyn suunnittelu tai nykyisten käyttäjätilien liittäminen Haka-kirjautumisesta saatavaan identiteettiin. Joidenkin sovellusten kohdalla tai hankalien riippuvuussuhteiden hallitsemiseksi joskus joudutaan valmistautumaan laajemmin ja varamaan aikaa huomattavasti tässä mainittua enemmän.
Hakan käyttö
Yritin kirjautua Hakalla palveluun X, mutta kirjautuminen epäonnistui
Haka-operoinnin tukipalvelu on tarkoitettu Haka-palvelujen ja kotiorganisaatioiden tunnistuslähteiden SAML-palvelimien tekniselle ylläpitohenkilöstölle.
Yleisin syy loppukäyttäjän kirjautumisvirheisiin on väärä käyttäjätunnus tai salasana. Loppukäyttäjän käyttäjätunnuksiin liittyvissä ongelmissa on otettava yhteyttä oman kotiorganisaation IT-helpdeskiin.
Haka on hajautettu järjestelmä, jossa loppukäyttäjät kirjautuvat palveluihin oman kotiorganisaationsa tunnuksilla. Joskus saattaa olla yhteensopivuusongelmia henkilötietojen välittämisessä kotiorganisaation tunnistuslähteen ja palvelun välillä. Tällaisissa tilanteissa joko palvelu tai kotiorganisaation tunnistuslähde antaa näkyville virheilmoituksen, joka on teknisen ylläpitohenkilöstön ensimmäinen vihje vian löytämiseen. Loppukäyttäjän voi olla mahdollista jo vikailmoituksesta päätellä, onko syytä ottaa yhteys omaan kotiorganisaatioon, vai palvelun ylläpitoon.
Vikailmoituksessa järjestelmän antaman virheilmoituksen lisäksi ensiarvoisen tärkeää on ilmoittaa päivämäärä ja tarkka kellonaika (sekä ulkomailla aikavyöhyke), jolloin vika ilmeni. Tarkan kellonajan lisäksi voit liittää vikailmoitukseesi kuvakaappauksen saamastasi virheilmoituksesta. Liitä mukaan myös selkeä kuvaus siitä, mitä olit tekemässä ja missä vaiheessa kirjautumisprosessia vika ilmaantui.
Viat ovat harmillisia ja olemme luonnollisesti pahoillamme kohtaamastasi haitasta. Vaikka olemme varautuneet lähes kaikkeen mahdolliseen, toisinaan eteen tulee tilanteita, jotka ylittävät odotuksemme. Tekemäsi selkeä ja kattava vikailmoitus on sijoitus seuraavaa vastaavaa tilannetta varten, jossa joku muu on ehtinyt jo tehdä hyvän vikailmoituksen sinun puolestasi ennen kuin edes huomaat mitään vikaa olleenkaan.
Eikös tämän pitänyt olla kertakirjautumista? Miksi minua pyydetään kirjautumaan uudelleen?
Webin ytimessä toimivaa HTTP-protokollaa kutsutaan tilattomaksi. Sivulatauksiin liittyvät kutsut ovat sikäli toisistaan irrallisia, että kahden eri sivulatauksen välillä ei pelkän pyynnön perusteella välity tieto siitä, kuka palvelua käyttää (ellei sitä erikseen pyynnössä jollain tavalla ilmaista). Tätä varten web-tekniikassa käytetään erilaisia istunnonhallinnaksi kutsuttuja menetelmiä käyttäjätiedon selvittämiseksi turvallisesti sivulatausten yhteydessä. Yleisin tapa on käyttää selaimeen tallennettuja evästeitä (cookie). Perusohjeistus on, että evästeet unohtuvat, kun selain suljetaan. Avaimesi avoimiin istuntoihin siis häviävät muistista, kun suljet selaimen. Avattuasi selaimen uudelleen, joudut myös kirjautumaan uudelleen.
SAML-kirjautumisen yhteydessä sinulla on istunto paitsi omassa tunnistuslähteessäsi, myös niissä palveluissa, joihin olet kirjautunut tekniikkaa käyttäen. Näiden istuntojen pituudet vaihtelevat. Jokainen organisaatio ja palvelu määrittelee istunnon maksimipituuden (session lifetime) ja ajan, jonka se voi olla joutilaana (session inactivity). Palvelu voi myös erikseen vaatia uudelleenkirjautumista siitäkin huolimatta, että istunto tunnistuslähteellä on vielä voimassa.
Olen etätöissä kotona / ulkomailla / nettikahvilassa / hotellissa ja joudun jatkuvasti kirjautumaan uudelleen. Miksi istunnot eivät säily?
Kirjauduin ulos palvelusta, mutta mennessäni toiseen palveluun tai samaan palveluun uudelleen, minulta ei kysytä tunnusta ja salasanaa! Onko tämä turvallista?
Haka perustuu SAML-tekniikkaan, jonka ytimessä on kertakirjautuminen. Niin pitkään, kuin istuntosi (kts. edellinen kohta) on tunnistuslähteellä voimassa, sinun ei tarvitse kirjautua uudelleen ellei palvelu sitä erikseen pyydä. Jokainen organisaatio ja palvelu määrittelee oman tietoturvapolitiikkansa perusteella, kuinka pitkään istunto on voimassa.
Kertakirjautuminen on kohtuullisen helppo toteuttaa, mutta uloskirjautuminen kaikista palveluista ja tunnistuslähteeltä ei ole aivan yhtä suoraviivaista. Tähän liittyvät ongelmat on kuvattu hyvin Shibboleth-ohjelmiston wiki-sivulla englannin kielellä.
Olen toteuttamassa uutta Haka-ominaisuutta palveluumme. Voinko saada teiltä testitunnukset ominaisuuden testaamiseen?
En muista Haka-tunnustani. Voitteko lähettää minulle uuden salasanan?
SAML-profiili
Autentikaatiopyynnön allekirjoittaminen
Hakassa noudatetaan julkishallinnon yhteistä SAML 2.0 profiilia muutamin täydennyksin. Profiili edellyttää, että palvelu (SP) allekirjoittaa autentikaatiopyynnöt. Oletusarvoisesti Shibboleth-ohjelmisto ei allekirjoita autentikaatiopyyntöä. Allekirjoituksen saa päälle esim. asettamalla shibboleth2.xml -tiedostossa ApplicationDefaults -elementin signing-attribuutti asentoon "true" tai "front".
<ApplicationDefaults entityID="https://testsp.nonexistent.tldn/shibboleth"
REMOTE_USER="eppn persistent-id targeted-id"
signing="front" encryption="false">
Turvallisuus
Haka-operoinnin keskitetyt palvelut tuottava haka.funet.fi on pilvipalvelussa. Aiheutuuko tästä riskiä tietosuojalle?
Palvelimella haka.funet.fi on kaksi Hakan toiminnan kannalta keskeistä palvelua:
Palvelujen keskeisen luonteen takia niillä on useampia vaihtoehtoisia alustoja. Ongelmatilanteissa tai esim. huollon yhteydessä palvelut on mahdollista siirtää kulloinkin soveltuvimmalle alustalle. Siirtoja tehdään vain perustellusta syystä.
Eräs palvelun vaihtoehtoinen alusta on yhdysvaltalaisen Amazonin toteuttamassa pilvipalvelussa. Alusta sijaitsee fyysisesti Euroopan Unionin alueella Irlannissa. Euroopan Unionin valtiot ovat periaatteessa sitoutuneet yhtenäiseen henkilötietojen suojan tasoon, vaikkakin on ilmennyt, että USA:n turvallisuusviranomaisilla on laajat oikeudet saada käyttäjätietoja amerikkalaisilta IT-yrityksiltä. Viimeksi 2013 kesäkuussa mediassa tuotiin taas esille epäilyjä eräiden valtioiden suorittamasta tietoliikenteen seurannasta. Epäiltiin, että kansalaisten tietoliikennettä seurattaisiin ja käytettäisiin terrorismin ja vakavien rikosten ehkäisyyn sekä mahdollisesti myös muuhun tiedustelutyöhön varsin laajamuotoisesti [Tempora] [Prism] [Patriot Act].
Pilvipalvelun ylläpidolla ja edellä mainituilla tahoilla on teknologian puolesta mahdollista seurata myös haka.funet.fi palvelujen tietoliikennettä niiden toimiessa pilvialustalla.
Purkamatta tietoliikenteen salausta ja seuraamalla haka.funet.fi palveluihin tehtyjä HTTP-GET -pyyntöjä on mahdollisuus saada seuraavia tietoja:
- mistä IP-osoitteesta on noudettu Haka-metadataa
- mistä IP-osoitteesta on käytetty keskitettyä tunnistuslähteen päättelypalvelua
- käytettäessä keskitettyä tunnistulähteen päättelypalvelua
- mihin palveluun on yritetty kirjautua
Haka-metadata on julkista tietoa ja joka tapauksessa saatavilla internet-verkosta, joten tältä osin pilvipalvelun käyttöön ei nähdä sisältyvän erityistä tietosuojariskiä. haka.funet.fi -palvelussa ei välitetä IP-osoitteen lisäksi muuta henkilötietoa. Suomen Tietosuojalautakunnan tulkinnan mukaan IP-osoite on pääsääntöisesti henkilötieto. Myös vastakkaisia tulkintoja on esitetty ("usein yhden ip- osoitteen takaa löytyy monta käyttäjää").
Tunnistuslähteen päättelypalvelun liikenne on suojattu TLS-protokollalla. HTTPS-GET pyyntöjen URL on tietoliikenteen seurannalla luettavissa salausta purkamatta, jolloin edellä luetellut tiedot on kätettävissä. Jos salaus onnistutaan purkamaan, on mahdollista HTTPS-POST -pyynnön yhteydessä kulkevan tiedon avulla selvittää, minkä kotiorganisaation käyttäjä on valinnut päättelypalvelusta. Väitetään, että joidenkin salausalgoritmien purkaminen on mahdollista suurella laskentateholla.
Käyttäjän kotiorganisaation selvittäminen saattaa edesauttaa verkkourkinnan toteuttamista. Joissain tilanteissa urkkijan saattaa olla mahdollista eri lähteistä saatua tietoa hyödyntäen selvittää, kuka on kulloinkin käyttänyt tiettyä IP-osoitetta. Tunnistuslähteen päättelypalvelun liikennettä seuraamalla ja eri lähteistä saatua tietoa yhdistelemällä voi olla periaatteellinen mahdollisuus saada lisätietoa, jota muuten ei olisi käytettävissä. Tosin kotiorganisaation selvittäminen lienee helpompaa louhimalla internet-verkosta yleisesti saatavilla olevia tietoja tai käyttämällä muita henkilöön, hänen käytössään oleviin laitteisiin, palveluihin tai tietoliikenneyhteyksiin meneviä urkinnan keinoja.
Pitkäaikaisella tietoliikenteen seurannalla on mahdollista selvittää tilastotietoa siitä, mitkä IP-osoitteet käyttävät Hakan palveluja tai esim. siitä, mitkä Hakan palvelut tai tunnistuslähteet ovat suosituimpia. Näin voidaan myös saada selville, miltä maantieteellisiltä alueilta palveluja käytetään eniten. Osin vastaava tilastotieto on julkista ja saatavilla esim. CSC:n vuosikertomuksesta.
Keskitetty tunnistuslähteen päättelypalvelu on mahdollista sivuuttaa käyttäen suoria kirjautumislinkkejä tai palveluun upotettua päättelupalvelua. Haka-EDS ei kuitenkaan ole tällainen keskitetyn palvelun sivuuttava palvelu, vaan on käytettävä muita paikallisesti palvelussa toimivia ratkaisuja.
Varmenteet
SAML-varmenne on vanhenemassa / jo vanhentunut, mutta uusi varmenne on vasta haussa!
Hakassa käytettävän SAML-viestien vaihdon suojaamiseen tarkoitetun varmenteen uusimiseen on varattava aikaa n. kuukausi. Tähän ei sisälly varmenteen tekemiseen tai hankkimiseen tarvittava aika. Varmenteen vaihtaminen tehdään niin, että se ei aiheuta katkoa tai haittaa palvelun käytölle. Vaihtoprosessi on kuvattu tarkemmin erillisessä ohjeessa.
SAML-varmenne julkaistaan muille verkoston entiteeteille Haka-metadatassa. Hakassa metadatan normaali julkaisusykli on noin kerran kahden viikon aikana. Metadatan julkaisua voidaan aikaistaa painavasta syystä. Hakassa on lähes 200 entiteettiä, joiden varmenteet uusitaan säännöllisesti. Varmenteen vanhenemiseen on mahdollista varautua etukäteen ja tästä syystä varmenteen vanhenemista ei yleisesti katsota painavaksi syyksi poiketa normaalista metadatan julkaisusyklistä.
Varmennekäytännössä on määritetty, minkälaisia varmenteita Hakassa voidaan käyttää. Huomaa, että käyttäjälle näkyvän HTTP-liikenteen suojaamiseen käytettävän SSL-varmenteen ei tarvitse olla sama, jota käytetään Hakassa SAML-viestien suojaamiseen. Kiiretilanteessa kannattaa uudistaa SSL-varmenne erikseen ja SAML-varmenne rauhassa prosessin mukaisesti.
Määritysten mukaan toimivat SAML-tuotteet toimivat myös vanhentunutta varmennetta käytettäessä. Metadata-iop toteaa seuraavaa:
"In the case of an X.509 certificate, there are no requirements as to the content of the certificate apart from the requirement that it contain the appropriate public key. Specifically, the certificate may be expired, not yet valid, carry critical or non-critical extensions or usage flags, and contain any subject or issuer. The use of the certificate structure is merely a matter of notational convenience to communicate a key and has no semantics in this profile apart from that. However, it is RECOMMENDED that certificates be unexpired."
Esim. Shibboleth-ohjelmistoa käyttävät entiteetit toimivat ongelmitta myös vanhentuneella varmenteella.
Haluan uudistaa SAML-varmenteen lennosta noudattamatta prosessia, onnistuuko se?
SAML-varmenteen voi uusia myös "lennosta" korvaamalla vanha varmenne uudella. Tämä aiheuttaa katkon palvelun käyttöön, sillä verkoston muut entiteetit on ohjeistettu päivittämään metadatansa vähintään kerran vuorokaudessa. Entiteetit päivittävät metadatansa eri aikaan ja ennen kuin uusi varmenne on tullut kaikkien muiden entiteettien tietoon, tarvitaan aikaa vähintään vuorokausi. Jos kyse on palvelusta, jota käytetään vain muutamasta organisaatiosta, on mahdollista sopia näiden kanssa, että ne päivittävät metdatansa välittömästi sen julkaisemisen jälkeen.
Jos päätät uudistaa varmenteen lennosta,
- neuvottele Haka-operoinnin kanssa metadatan julkaisuajankohdasta
- SP:n ollessa kyseessä sovi palvelua käyttävien organisaatioiden kanssa, että niiden IdP:t noutavat uuden metadatan välittömästi sovitun julkaisuajankohdan jälkeen
- IdP:n ollessa kyseessä sovi keskeisten palvelujen kanssa, että ne noutavat uuden metadatan välittömästi sovitun julkaisuajankohdan jälkeen
- vaihda SAML-tuotteesi varmenne samaan aikaan, kun uusi metadata julkaistaan