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.

Haka-kirjautumisen käyttöönottoa voi edistää testaamalla palvelun Haka-integraatio valmiiksi jo ennen sopimuskierron valmistumista. 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 henkilötietojen välittämisessä kotiorganisaation tunnistuslähteen ja palvelun välillä saattaa olla yhteensopivuusongelmia. 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.

Vikailmoitusta tehdessä saadun virheilmoituksen lisäksi ensiarvoisen tärkeää on tietää päivämäärä ja tarkka kellonaika, 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. Auttaaksesi seuraavia käyttäjiä saamaan palvelun mahdollisimman nopeasti uudelleen käyttöön, tekemäsi selkeä vikailmoitus on sijoitus seuraavaa vastaavaa tilannetta varten, jossa joku muu on jo tehnyt hyvän vikailmoituksen sinun puolestasi.

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 perusteella ei pelkän pyynnön perusteella säily tietoa 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 saamiseksi 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.

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.

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">

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 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