Edellisessä artikkelissa käsittelimme kertakirjautumisen taustaa ja määrittelimme, mitä kertakirjautuminen on. Tässä artikkelissa keskitymme uudempiin kertakirjautumisen yhteyskäytänteisiin, joita käytetään erityisesti myös federoidussa kirjautumisessa.
Perinteisten yhteys- ja tunnistuskäytänteiden esiin tuominen edellisessä artikkelisarjan osassa oli tärkeää, jotta nähdään kertakirjautumisen kehittymisen kaari. Uudempiin protokolliin tutustumisen aloitamme varttuneen, mutta edelleen vahvan käytänteen, eli SAML:n kautta. Vuosituhannen vaihteessa määritettiin yleiseen käyttöön levinnyt edelleen hyvin laajasti käytössä oleva SAML-protokollakehikko.
SAML pohjautuu XML-kuvauskieleen ja SAML-viestit välitetään XML-muotoisina. XML on kattava kuvauskieli, sillä siinä on tuettuna laaja kirjo ominaisuuksia kuten skeemat, joilla voidaan todentaa viestin määrämuotoisuus. XML:ssä on kuvattu myös erittäin tarkasti viestien allekirjoitusten käsittely ja viestien kryptografinen suojaaminen käyttäen vahvoja salausmenetelmiä. Näitä tärkeitä piirteitä ei enää tarvitse toistaa SAML-protokollan tasolla, joskin profiileissa on jouduttu ottamaan kantaa joihinkin turvallisen viestinvaihdon käytänteisiin ja salausalgoritmien käyttöön.
XML:n tukemien ominaisuuksien ansiosta SAML-viestien todentamisessa toteutetaan monikerroksista suojausta, joka voi alkaa siitä, että viesti hylätään, jos se ei ole määrämuotoinen. Laskentatehoa vaativat operaatiot, kuten allekirjoituksen tarkastaminen tai salauksen purku voidaan jättää tehtäväksi vasta kun viesti on läpäissyt määrämuotoisuustestin.
Yleisesti keskusteluissa SAML nähdään vain yhtenä protokollana tai määrityksenä, mutta kuten WS-Federation:n tapauksessa, kyseessä on laaja perhe määrityksiä, joissa ei pelkästään kuvata turvallista viestinvaihtoa osapuolien välillä, vaan myös miten osapuolien välille muodostetaan luottosuhde, miten teknistä metatietoa osapuolien ominaisuuksista vaihdetaan ja minkälaisia profiileja noudatetaan erilaisissa päätelaiteympäristöissä ja verkoissa.
Parhaiten tunnettu ja eniten käytetty profiili SAML:ssa on Web Browser SSO Profile. Vertailun vuoksi, vastaavasti on määritelty esim. ECP-profiili, joka sopii erityisesti Webin ulkopuoliseen tunnistamiseen esimerkiksi natiivien mobiiliapplikaatioiden käyttötapauksessa tai konekielisten palvelujen keskinäisessä tunnistamisessa.
Keskitytään Web SSO profiiliin. SAML:n 2. version myötä profiili yksinkertaistui, kun SAML1:ssä käytetyistä artifakteista luovuttiin. SAML1:ssä tehtiin tunnistamisen jälkeen erillinen attribuuttikysely, jolla saatiin käyttäjästä lisätietoja, eli attribuutteja. Attribuutit ovat tiedonmurusia jotka kertovat käyttäjän oninaisuuksista. Niitä ovat esimerkiksi tieto käyttäjän nimestä, sähköpostiosoitteesta, profiilikuvasta ja vaikkapa kengän numerosta. Attribuutit välitettiin SAML1:n aikana artifakteina.
SAML2:n Web SSO -profiilissa voidaan HTTP-Post sidonnan (binding) yhteydessä kaikki tunnistustapahtumaan liittyvä tieto – attribuutit mukaan lukien – palauttaa yhdessä ja samassa tunnistusvastauksessa (Authentication Response). Tunnistusvastaus sisältää vakuutuksen (Assertion), jossa tunnistuspalvelin vakuuttaa tunnistaneensa käyttäjän sovitulla tavalla ja kertoo käyttäjän ominaisuuksista ja mm. siitä, miten, missä yhteydessä ja kuinka pitkään kyseistä tunnistusvastausta voi hyödyntää.
Web SSO HTTP-Post -sidonnan yhteydessä erityisen hyödyllistä on, että kaikki tieto välitetään käyttäjän selaimessa. Tunnistukseen tukeutuvan palvelun ja tunnistuspalvelun välillä ei tarvita suoraa TCP/IP-tason tietoliikenneyhteyttä, vaan riittää, että käyttäjän selaimella on TCP/IP-yhteydellä pääsy sekä tunnistuspalvelimeen, että tunnistukseen tukeutuvaan palveluun.
Tämä piirre on erityisen hyödyllistä toteutettaessa kertakirjautumista organisaatioiden välillä. Organisaatiot haluavat suojata verkkonsa ulkopuollisten pääsyltä palomuureilla ja perinteisesti kertakirjautumisen toteuttaminen organisaatiorajojen yli on vaatinut hankalia yhteydenavauksien prosesseja ja tietoliikenneyhteyksien avaamisesta sopimista.
SAML on koettu hankalaksi toteuttaa. Tämä johtuu todennäköisesti pitkälti siitä, että protokollaperhe on valtavan laaja. Sen toteuttaminen vaatii syvällistä tuntemusta IT-alalla hyvin monelta eri osa-alueelta ja vielä käytännön prosessien toteuttamisesta. SAML onkin väistynyt uusien, väitetysti yksinkertaisempien protokollien edestä. Totuus piilee yksityiskohdissa ja syy SAML:n monimutkaisuuteen on se, että tietoturvallisuuteen ja henkilöiden tietosuojaan liittyviä asioita on pohdittu syvällisesti. Kertakirjautuminen on monimutkainen kokonaisuus. Näennäisesti yksinkertaisen protokollan edessä on kysyttävä: “onko tämä myös turvallinen”.
Onkin tapana sanoa, että uutiset SAML:n kuolemasta ovat ennenaikaisia. SAML on niin syvälle juurtunut, että se ei häviä maailmalta vielä pitkään. Silti niin on, että uusia teknologioita on noussut ja ne ottavat alaa myös organisaatiorajat ylittävässä kertakirjautumisessa.
Keskeisin kilpailija SAML:lle yhteyskäytänteen tasolla on OIDC – Open Id Connect. OIDC pohjautuu OAuth2-protokollaan, joka määriteltiin enemmänkin käyttövaltuuden delegointiin. Keskeisessä roolissa OAuth2:ssa ovat käyttäjän lisäksi varsinainen tunnistuspalvelu, mutta myös resurssipalvelin, jonka resursseihin käyttäjälle tai hänen valtuuttamaan tunnistamiseen tukeutuvaan palveluun käyttäjä sallii pääsyn.
OIDC on OAuth2-protokollan päälle toteutettu ja täysin sen kanssa yhteensopiva lisäkerros, joka keskittyy valtuuttamisen sijasta tarkemmin käyttäjän luotettavaan tunnistamiseen. Siinä, missä SAML perustaa XML:n varaan, OIDC perustuu JSON-muotoisien viestien välittämiseen.
Aivan kuten XML:ssä, JSON:n yhteyteen on määritelty mm. JWS (JSON Web Signature), JWK (JSON Web Key) sekä JWE (JSON Web Encryption) -käytänteet, joiden avulla turvataan viestinvälityksen luotettavuutta. Väitetään, että JSON on kuvauskielenä XML:a selkeämpi. Siitä puuttuukin ominaisuuksia, joita XML:n yhteyteen on vuosien varrella määritetty ja siinä mielessä JSON-määritelmäperhe on helpompi ja nopeampi omaksua. Kuitenkin, kun OIDC:n määrityksiä alkaa penkoa, huomaa, että tärkeitä toteutukseen liittyviä yksityiskohtia löytyy sieltäkin.
JSON:n ja OIDC:n selkeyden mielikuva saattaa piillä siinä, miten JSON monen mielestä on ihmissilmälle selkeämmin luettavissa. XML saadaan näyttämään tarvittaessa ihmiselle luettavalta, mutta missään nimessä sellainen ei ole tarkoituksenmukaista. JWS-viestien rakenne on sellainen, että kehittäjät pystyvät keveillä työkaluilla purkamaan viestin osiinsa ja tarkastella viestin sisältöä silmämääräisesti. JSON Web Token:ien (JWT) piirre on myös se, että ne ovat keveitä ja helposti siirrettäviä. Tunnistus-token on siis helposti luovutettavissa kolmannelle osapuolelle ikään kuin vahvistamaan tunnistamisen tapahtuneen.
OIDC:n selkeydessä on kuitenkin helppo myös mennä metsään. Jostain syystä kehittäjien joukossa vallitsee kuvitelma, että pelkkä tokenin läsnäolo vahvistaa asioita ja tekee tunnistamisesta turvallista ja luotettavaa. OIDC:ssa on käytössä hallintaan perustuvia tokeneita (bearrer token).
On helppo ymmärtää, miksi on kehittynyt tosielämän fyysisiin avaimiin vertautuva analogia, että tokenin esittämällä voisi saada valtuuden johonkin operaatioon, avata pääsyn ovesta eteenpäin. Digimaailman ovet ja lukot vaativat kuitenkin hallinnointia aivan kuten tosielämän vastineensa ja ollessaan Internet-verkossa paljon helpommin hyökkäyksille alttiina, ne vaativat tosielmän vastineita tarkempaa huomiota.
OAuth2-protokollan tasolla on tarkkaan määritetty, miten tokeneita käytetään valtuuttamiseen. Myös OIDC-protokollan tasolla kuvataan profiileissa, miten tokeneita hyödynnetään. OIDC:n profiilit eivät ole vastaavalla tarkkuudella SAML:n kanssa. Niinpä monessa yhteydessä onkin jouduttu määrittämään varsinaista ydinmääritystä (OIDC-core) täydentäviä profiileja OIDC:n ympärillle. Paikallisissa profiileissa tarkennetaan yksityiskohtia, joihin ydinmäärityksessä ei ole otettu kantaa.
OIDC määrittelee Implicit flow:n, joka perustuu yksittäisen tokenin välittämiseen tunnistukseen tukeutuvalle palvelulle. Idea on sama, kuin SAML2:n Web SSO Profiilissa, jossa kirjautumisen todentamisessa tarvittava tieto välitetään käyttäjän selaimessa. OIDC Implicit Flow:ssa todentaminen perustuu tokenin allekirjoituksen tarkastamiseen tunnistuspalvelun metatietoihin perustuen.
Implicit Flow on erityisen kätevä moderneissa yhden sivun toteutuksissa (SPA – Single Page Application), jossa tunnistamisen edustatoteutus (frontend) voidaan jättää JavaScript-kirjastojen toteutettaviksi ja taustalle (backend) välitetään edustalta JWT, jonka avulla tunnistustapahtuma voidaan todentaa ja avata API Gateway -tuotteessa pääsy taustapalveluhin. Implicit Flow:sta toisaalta puuttuu käytänne esim. istunnon voimassaolon tarkistamiseen. Käytettäessä Authorisation Code Flow -profiilia käytössä on Introspection-palvelu, josta voidaan kysellä käyttäjän istunnon voimassaoloa. Istunnon voimassaolon todentaminen ei perustu pelkästään tokenin voimassaolon aikaleimaan, vaan se voidaan keskeyttää tokenista riippumattomasti.
OIDC sisältää piirteitä, joiden ansiosta se taipuu hyvin haastaviinkin mikroarkkitehtuuriratkaisuihin. Näissä taustajärjestelmä on hajautettu pieniin mikropalveluihin ja edustatoteutus erotetaan taustajärjestelmästä.
Emme voi vielä päättää tätä artikkelisarjan osaa mainitsematta kahta aivan uutta käytännettä: WebAuthn ja Fido. Fido on Fido-allianssin ja WWW-konsortion (W3C) projekti, jonka tavoitteena tuoda vahva tunnistaminen www-verkkoon. Fido keskittyy erityisesti tunnistusvälineen rekisteröintiin ja käyttöön web-palveluun kirjautumisessa.
WebAuthn on Fidon ydinkomponentti. Projekin tavoite on standardoida rajapinnat käyttäjän tunnistamisesta verkkopalveluun käyttäen julkisen avaimen salakirjoitustekniikoita.
WeBAuthn/Fidon avulla määritellään, miten tunnistusväline kytketään luotettavalla tavalla palvelun yhteyteen, jotta käyttäjä voi luotettavasti kirjautua palveluun. Keskeisiä tekijöitä ovat, että käyttäjä voi varmistua, että turvatekijä kytketään luotettavasti juuri käyttäjän tarkoittamaan palveluun ja toisaalta, että tunnistamiseen tukeutuva palvelu luottaa käyttäjän tunnistustekijään, se on saman käyttäjän hallussa, joka tunnistustekijää käytti rekisteröinnin yhteydessä.
Edelliset asiat kuulostavat äkkiä ilmeisiltä, mutta sisältävät kasvavien hyökkäyksien internet-ympäristössä paljon pieniä yksityiskohtia, joissa yksikin pieni virhe saattaa aiheuttaa sen, että palveluun pääseekin esimerkiksi käyttäjää harhauttamalla joku toinen henkilö, kuin kenen oli tarkoitus.
WebAuthn/Fidon keskiössä on mm. uudet päätelaitteet, joihin on toteutettu erillinen suojattu enklaavi (Trusted Platform Module – TPM). Suojattu enklaavi mahdollistaa käyttäjän tunnistustekijöiden taltioimisen muusta laitteen käyttöjärjestelmästä erillään siten, että niihin on pääsy vain valtuuteuilla palveluilla. Käytännössä tämä tarkoittaa sitä, että esimerkiksi jos käyttäjä on rekisteröinyt sormenjälkensä käytettäväksi tunnistustekijänä palveluun, vähintään kaikki seuraavan luettelon asioista toteutuu:
WebAuthn/Fidon keskittyminen uusiin käyttäjien mobiililaitteissa toimiviin päätelaitteisiin ja biometrisiin tunnistusmenetelmiin on tehnyt Fidosta hyvän vaihtoehdon salasanalle. Monessa yhteydessä, kun puhutaan salasanattomasta tunnistamisesta, viitataan usein Fidoon tai WebAuthn-standardiin.
Salasanan korvaamisen lisäksi Fido on verraton vaihtoehto lisätunnistustekijänä perinteisten rinnalle. Kun puhutaan kaksivaiheisesta (2FA) tai monivaiheisesta tunnistamisesta, usein tarkoitetaan, että perinteisen käyttäjätunnuksen ja salasanan rinnalla (jotain, mitä käyttäjä tietää), pitää olla jokin toinen menetelmä, kuten biometrinen tunniste (jotain, mitä käyttäjä on). Fido on siinä mielessä vielä perinteistä vahvempi, että se sisältää kaksi vaihetta ikään kuin yhdessä paketissa. Biometerinen tunniste nimittäin toteutetaan usein käyttäjän omalla laitteella, jolloin toteutuu kaksi tekijää kerralla:
Monivaiheinen tunnistaminen on erityisessä roolissa, kun Euroopassa vahvistettiin käyttöön toinen maksupalvelufirektiivi (PSD2). PSD2 vaatimukset (Regulatory Technical Standards – RTS) edellyttävät kaksivaiheista tunnistamista mm. maksutapahtumia tehdessä.
Keskeinen huomio WebAuthn/Fido:n osalta on tehtävä. Kyseessä on standardi, jolla määritellään tunnistusvälineen käyttö palvelussa. WebAuthn-käytänteet eivät määrittele, miten tunnistusmenetelmää käytetään laajemmassa yhteydessä. Toisin on SAML:n ja OIDC:n osalta, joille on määritelty jo lähtökohtaisesti käytänteet paitsi organisaation sisäisessä kertakirjautumisessa, myös organisaatiorajat ylittävässä tunnistamisessa.
WebAuthn on nimenomaan kertakirjautumisen ytimessä. Jos palataan edellisen artikkelisarjan kertaukirjautumisen määritelmään, kyse on siis nimenomaan siitä, miten käyttäjä voidaan luotettavasti sitoa tunnistusvälineeseensä ja miten tämä tieto voidaan luotettavasti kuljettaa yhdelle tunnistamiseen tukeutuvalle palvelulle, eli täsmälleen sille palvelulle, jonka yhteydessä on sovittu kertakirjautumisen järjestestämisestä.
Seuraavassa artikkelisarjan osassa keskitymme kertakirjautumisen hallinnointiin ja pysähdymme kertakirjautumisen kannalta keskeiseen termin määritelmään: federoituun kirjautumiseen.
Käynnistän moniosaisen artikkelisarajan kertakirjautumisesta; mitä koen sen olevan ja miten se on kehittynyt. Aloitan ensimmäisessä artikkelissa kertakirjautumisen taustasta ja määritelmästä. Yritän otsikoida kokonaisuuden siten, että voit…
Tämä on moniosaisen artikkelisarjan kolmas osa, jossa keskitytään kertakirjautumisen hallinnointiin. Trendikäs vieraskielinen usein nykyään käytetty lyhyt termi lienee governance. Aiemmissa artikkelisarjan osissa käsittelimme kertakirjautumisen taustaa ja…
Artikkelisarjan viimeisessä osassa keskitytään kertakirjautumisen ja federoidun kirjautumisen hyötyihin ja haittoihin.
