Märkus. Repo on mõeldud avalikuks kasutamiseks. Skriptidest ja dokumentatsioonist eemaldatud RIA taristu tundlike nimede jm väärtuste mainimised. Samuti on repost eemaldatud võtmed ja serdid.
Vt ka:
- Riigi SSO teenuse projektlahendus
- Riigi SSO teenuse tehniline spetsifikatsioon ja protokolli kirjeldus (inglise keeles)
Prototüüp on makettrakenduste kogum, mis võimaldab kasutajal läbi teha SSO kõik olulised kasutusvood. Prototüüp teostatakse vastavalt projekti tööde kirjelduse p 3.1 järgi väljatöötatud projektlahendusele (Riigi SSO teenuse projektlahendus). Prototüübi eesmärk on maandada teostatavusriski, turvariski ja kasutatavusriski. Prototüüp ei ole mõeldud evitamiseks toodangukeskkonda.
Prototüübi realiseerimisel kasutati levinud OpenID Connect (OIDC) protokolli toega tarkvarakomponente. Valdavalt on kasutusel Java tehnoloogiad ja Spring Boot raamistikku, sest arendus antud platvormil on tellijale tuttav ja prototüüpimine võrdlemisi lihtne. Spring Boot on laialt levinud Java tarkvara raamistik. POC-i käigus tahtsime tõestada Spring Security (Spring raamistiku turvatäienduste paketi) sobivust standardse OIDC klientrakenduse implementeerimiseks. GOVSSO taustasüsteemi tuumikuna otsustati katsetada Go keeles kirjutatud ORY Hydra platvormi. Prototüübi Hydra serveri vahelehtede disainis on kasutatud TARA teenuse kasutajaliidese komponente, mis põhinevad Veera raamistikul. Klientrakenduse disainis on kasutatud Bootstrap disainiraamistikku.
ORY Hydra näol on tegemist vabavaralise Oauth 2.0 ja OIDC protokolli implementeeriva serverirakendusega. Hydra kasuks räägivad tema lihtsus ja paindlikkus. Vaikimisi pakutakse ainult elementaarset OIDC protokolli voogude (autoriseerimiskoodi voog) ja OIDC seansihalduse laienduste tuge. Kasutajate haldus ja identifitseerimine on tarvis lahendada eraldi mikroteenustena. Hydra on OpenID Foundation poolt sertifitseeritud OIDC server. Tänu oma modulaarsele arhitektuurile sobib ta madalate vasteaegade ja suure läbilaskevõimega teenuse pakkumiseks. POC-i käigus üritati muuhulgas kinnitada või ümber lükata Hydra platvormi tehniline sobivus GOVSSO lahendamiseks. Täna on teada, et ka tulevane TARA teenuse arhitektuur baseerub Hydra platvormil. Kuivõrd TARA ja GOVSSO teenuste arendused on väga lähedalt seotud, siis on sama platvormi kasutamine mõlema teenuse taustasüsteemis otstarbekas. POC-i implementatsiooni käigus tulid välja mõned olulised Hydra platvormi tehnilised puudujäägid, millega tuleb tulevase GOVSSO teenuse implementeerimisel kindlasti arvestada (vt. Lisa 1)
POC-i käigus arendati järgmised tarkvarakomponendid:
sso-client: GOVSSO-d kasutava klientrakenduse makett, mis võimaldab läbi mängida kasutaja autentimise erialdiseisvate e-teenuste lõikes sama SSO seansi raamessso-oidc-server: GOVSSO-d implementeeriv Hydra serverirakendus ja konfiguratsioonsso-login-server: Hydra kasutajate identifitseerimise ja osaliselt seansi halduse samme implementeeriv mikroteenus.sso-oidc-server-db: GOVSSO Hydra serveri andmebaas ja selle algseadistamise skriptid- Evituskeskkonna tehniline kirjeldus ja skriptid. GOVSSO makettrakendus ja selle komponentide paigaldamiseks täitja keskkonnas toimus Docker konteinerite ning docker-compose konteinerite orkestreerimise tööriista kaudu.
- Eraldi TARA teenuse maketti POC rakenduse jaoks ei koostatud. Selle asemel on kasutusel RIA riigi autentimisteenuse testkeskkond.
Joonis 1: GOVSSO POC-i komponentide mudel
Töötav POC on praegu kättesaadav RIA-s sisemiselt.
GOVSSO POC-is kasutakse autentimiseks riigi autentimisteenuse testkeskkonda https://e-gov.github.io/TARA-Doku/Testimine.
POC programmi kood, evitusjuhend ja rakenduste seadistamise juhend asub antud repositooritumi alamkataloogis: sso-poc-environment
- Kasutaja avab sirvikus Klientrakendus 1 e-teenuse avalehe
- Kasutaja vajutab "Logi sisse" nuppu Klientrakendus 1 e-teenuse avalehel.
Kuna kasutajal puudub aktiivne SSO seanss, siis suunatakse ta otse TARA teenuse autentimisvahendite valiku lehele.
- Kasutaja autendib ennast Mobiil-ID abil
- Eduka autentimise järel tekitab GOVSSO kasutajale SSO seansi ja suunab sirviku tagasi Klientrakendus 1 e-teenuse tagasisuunamise URL-ile.
Kasutaja on klientrakendusse sisse logitud, sirvikus kuvatakse Klientrakendus 1 e-teenuse töölaud.
- Kasutaja avab sirvikus Klientrakendus 1 e-teenuse avalehe
- Kasutaja vajutab "Logi sisse" nuppu Klientrakendus 1 e-teenuse avalehel.
Kuna kasutajal puudub aktiivne SSO seanss, siis suunatakse sirvik otse TARA teenuse autentimisvahendite valiku lehele.
- Kasutaja autendib ennast TARA-s Mobiil-ID abil
- Eduka autentimise järel tekitab GOVSSO kasutajale SSO seansi ja suunab sirviku tagasi Klientrakendus 1 e-teenuse tagasisuunamise URL-ile.
Kasutaja on Klientrakendus 1 e-teenusesse sisse logitud, sirvikus kuvatakse Klientrakendus 1 e-teenuse töölaud.
- Kasutaja avab sirviku uues sakis Klientrakendus 2 e-teenuse avalehe
- Kasutaja vajutab "Logi sisse" nuppu Kilientrakendus 2 e-teenuse avalehel.
Kuna kasutajal eksisteerib aktiivne SSO seanss, siis suunatakse sirvik otse GOVSSO sisselogimise teavituse vahelehele.
Vahelehel on näha hetkel GOVSSO-s aktiivse seansiga seotud isiku andmed ja Klientrakenduse 2 e-teenuse nimi koos logoga.
- Kasutaja soovib Klientrakendus 2 e-teenusesse siseneda kehtiva SSO seansi raames.
Kasuta vajutab Sisselogimise teavituse lehel "Jätka sessiooni" nupu.
Taustal koostatakse Klientrakendus 2 e-teenuse jaoks uus identsustõend, mis on seotud sid väite abil kehtiva SSO seansiga. Sirvik suunatakse tagasi Klientrakendus 2 e-teenuse tagasisuunamise URL-ile.
Kasutaja on Klientrakendus 2 e-teenusesse sisse logitud, sirvikus kuvatakse Klientrakendus 1 e-teenuse töölaud.
- Kasutajale kuvatakse erinevates sirviku sakkides klientrakenduste töölaudade vaated koos vastava klientrakenduse seanssidega seotud identsustõendite sisudega.
Töölaual kuvatakse identsustõendite sid väide, mille abil kasutaja saab veenduda, et klientrakenduste identsustõendid on seotud sama SSO seansitunnusega.
Töölaual kuvatakse identsustõendite aud väide, mille abil kasutaja saab veenduda, et klientrakenduste identsustõendid on väljastatud korrektsetele klientrakendustele.
Vajutades töölaual nuppu "Värskenda seanssi" saab kasutaja veenduda, et mõlemal klientrakendusel õnnestub GOVSSO-lt pärida uus identsustõend (s.t. SSO seansi värskendamine õnnestub).
Iga "Värskenda seanssi" nupu vajutuse järel saab kasutaja veenduda, et identsustõendi järjekorranumber (jti väide) muutub.
- Kasutaja avab sirvikus Klientrakendus 1 e-teenuse avalehe
- Kasutaja vajutab "Logi sisse" nuppu Klientrakendus 1 e-teenuse avalehel.
Kuna kasutajal puudub aktiivne SSO seanss, siis suunatakse sirvik otse TARA teenuse autentimisvahendite valiku lehele.
- Kasutaja autendib ennast TARA-s Mobiil-ID abil
- Eduka autentimise järel tekitab GOVSSO kasutajale SSO seansi ja suunab sirviku tagasi Klientrakendus 1 e-teenuse tagasisuunamise URL-ile.
Kasutaja on Klientrakendus 1 e-teenusesse sisse logitud, sirvikus kuvatakse Klientrakendus 1 e-teenuse töölaud.
- Kasutaja avab sirviku uues sakis Klientrakendus 2 e-teenuse avalehe
- Kasutaja vajutab "Logi sisse" nuppu Klientrakendus 2 e-teenuse avalehel.
Kuna kasutajal eksisteerib aktiivne SSO seanss, siis suunatakse sirvik GOVSSO sisselogimise teavituse vahelehele.
Vahelehel on näha hetkel GOVSSO-s aktiivse seansiga seotud isiku andmed ja Klientrakenduse 2 e-teenuse nimi koos logoga.
- Kasutaja vajutab sisselogimise vahelehel "Autendi uuesti" nuppu.
Taustal toimub kehtiva GOVSSO seansi tühistamine.
Kuna SSO seansiga oli varasemalt sisse logitud ka Klientrakendus 1 e-teenusesse, siis saadab GOVSSO taustakanali kaudu väljalogimise tõendi ka Klientrakendus 1 e-teenuse serverikomponendile.
Klientrakendus 1 server kontrollib saadud väljalogimise tõendi korrektsust ja tühistab kehtiva Klientrakendus 1 seansi.
GOVSSO suunab sirviku edasi TARA autentimisvahendite valiku lehele.
- Kasutaja autendib ennast TARA-s Mobiil-ID abil
- Eduka autentimise järel tekitab GOVSSO kasutajale SSO seansi ja suunab sirviku tagasi Klientrakendus 2 e-teenuse tagasisuunamise URL-ile.
Kasutaja on Klientrakendus 2 e-teenusesse sisse logitud.
- Kasutaja liigub sirvikus tagasi Klientrakendus 1 e-teenuse saki peale.
Kuna Klientrakendus 1 e-teenuses pole realiseeritud aktiivset seansi oleku kontrolli, siis Klientrakendus 1 e-teenuse viimati kuvatud töölaua sisu endiselt kasutajale nähtav.
- Kasutaja saab veenduda, et Klientrakendus 1 seanss tühistati uue autentimise käigus automaatselt, värskendades sirviku lehe sisu (vajutades sirviku lehe värskendamise nuppu või lehe päises olevat Klientrakendus 1 e-teenuse logo).
Kuna Klientrakendus 1 tühistas kasutaja seansi sammul 7, siis puudub kasutajal kehtiv klientrakenduse seanss Klientrakenduse 1 e-teenuses.
Lehe värskendamise järel suunatakse kasutaja Klientrakendus 1 e-teenuse avalehele. Avalehel kuvatakse veateade varasema seansi lõpetatusest.
- Kasutaja saav veenduda, et tal on endiselt kehtiv seanss Klientrakendus 2 e-teenuses, liikudes tagasi sirviku sakile kus oli avatud Klientrakendus 2 e-teenuse töölaud.
Vajutades nuppu "Värskenda seanssi" väljastatakse Klientrakendus 2 e-teenusele uus identsustõend ja jti väite väärtus muutub.
- Kasutaja avab sirvikus Klientrakendus 1 e-teenuse avalehe
- Kasutaja vajutab "Logi sisse" nuppu Klientrakendus 1 e-teenuse avalehel.
Kuna kasutajal puudub aktiivne SSO seanss, siis suunatakse ta otse TARA teenuse autentimisvahendite valiku lehele.
- Kasutaja autendib ennast Mobiil-ID abil
- Eduka autentimise järel tekitab GOVSSO kasutajale SSO seansi ja suunab sirviku tagasi Klientrakendus 1 e-teenuse tagasisuunamise URL-ile.
Kasutaja on klientrakendusse sisse logitud, sirvikus kuvatakse Klientrakendus 1 e-teenuse töölaud.
- Kasutaja vajutab Klientrakendus 1 e-teenuse töölaua päises "Logi välja" nuppu
Taustal toimub sirviku automaatne suunamine GOVSSO teenuse väljalogimise URLile.
GOVSSO tuvastab, et kasutaja ei ole kehtiva SSO seansi raames sisse loginud mitte ühtegi teise klientrakendusse peale Klientrakendus 1 e-teenuse.
GOVSSO teostab automaatse SSO seansi tühistamise ja suunab sirviku tagasi Klientrakendus 1 e-teenuse tagasisuunamise URL-ile (näidisrakenduses on selleks URL-iks Klientrakendus 1 avaleht).
Antud kasutusjuhu kirjelduse lühiduse huvides jätame kirjeldamata sisselogimise osa. Antud kasutusjuhu eelduseks on, et kasutajal on kehtiv SSO seanss ja ta on antud SSO seansi jooksul sisse loginud kahte klientrakendusse. Sisselogimise sammud kattuvad täpselt eelpool kirjeldatud kasutusjuhu "Autentimine mitme klientrakenduse näitel" sammudega.
- Kasutaja teostab sisselogimise kahes klientrakenduses vastavalt kasutusjuhule "Autentimine mitme klientrakenduse näitel"
Kasutjal on kehtiv SSO seanss.
Sirvikus on avatud kaks sakki. Ühel sakil kuvatakse Klientrakendus 1 e-teenuse töölaud. Teisel sakil kuvatakse Klientrakendus 2 e-teenuse töölaud.
- Kasutaja vajutab Klientrakendus 1 e-teenuse töölaua päises "Logi välja" nupule.
Klientrakendus 1 tühistab klientrakenduse seansi (logib kasutaja välja Klientrakendus 1 e-teenusest).
Klientrakendus 1 suunab sirviku GOVSSO teenuse väljalogimise URL-ile.
GOVSSO tuvastab, et SSO seansi raames logiti sisse mitmesse klientrakendusse ja sellest tulenevalt kuvab väljalogimise vahelehe.
- Kasutale kuvatakse valik teistes klientrakendustes töö jätkamiseks või kõikide klientrakenduste seansside tühistamiseks.
Kasutaja vajutab "Logi välja" nupule, et tühistada terve SSO seanss ja sellega seotud klientrakenduste seansid.
GOVSSO tühistab SSO seansi.
GOVSSO saadab taustakanali kaudu väljalogimise tõendi Klientrakendus 2 e-teenusele
GOVSSO suunab sirviku tagasi Klientrakendus 1 e-teenuse väljalogimise suunamise URL-ile (poc rakenduses on selleks URL-iks Klientrakendus 1 e-teenuse avaleht).
- Kasutaja liigub sirviku sakile, milles kuvatakse Klientrakendus 2 töölaua vaade.
Kasutaja värskendab sirviku lehe sisu (vajutades sirviku lehe taaslaadimise nuppu või klõpsates Klientrakendus 2 e-teenuse päises olevale logole)
Klientrakendus 2 tuvastab, et klientrakenduse seanss on tühistatud ja suunab kasutaja Klientrakendus 2 e-teenuse avalehele koos veateatega "Seanss on lõpetatud!"
Antud kasutusjuhu kirjelduse lühiduse huvides jätame kirjeldamata sisselogimise osa. Antud kasutusjuhu eelduseks on, et kasutajal on kehtiv SSO seanss ja ta on antud SSO seansi jooksul sisse loginud kahte klientrakendusse. Sisselogimise sammud kattuvad täpselt eelpool kirjeldatud kasutusjuhu "Autentimine mitme klientrakenduse näitel" sammudega.
- Kasutaja teostab sisselogimise kahes klientrakenduses vastavalt kasutusjuhule "Autentimine mitme klientrakenduse näitel"
Kasutjal on kehtiv SSO seanss.
Sirvikus on avatud kaks sakki. Ühel sakil kuvatakse Klientrakendus 1 e-teenuse töölaud. Teisel sakil kuvatakse Klientrakendus 2 e-teenuse töölaud.
- Kasutaja vajutab Klientrakendus 1 e-teenuse töölaua päises "Logi välja" nupule.
Klientrakendus 1 tühistab klientrakenduse seansi (logib kasutaja välja Klientrakendus 1 e-teenusest).
Klientrakendus 1 suunab sirviku GOVSSO teenuse väljalogimise URL-ile.
GOVSSO tuvastab, et SSO seansi raames logiti sisse mitmesse klientrakendusse ja sellest tulenevalt kuvab väljalogimise vahelehe.
- Kasutaja vajutab nuppu "Jätka sessioone"
GOVSSO eemaldab Klientrakendus 1 seose SSO seansi juurest.
GOVSSO suunab sirviku tagasi Klientrakendus 1 avalehele.
- Kasutaja liigub sirviku sakile, milles kuvatakse Klientrakendus 2 töölaua vaade.
Kasutaja värskendab SSO seanssi (vajutades "Värskenda seanssi" nuppu).
Kasutaja saab veenduda, et uus identsustõend sisaldab endiselt sama sid väite väärtust ning seansi uuendamine õnnestub.
Autentimise algatanud klientrakenduse nimi kuvatakse TARA kasutajaliideses ja autentimisvahendi ekraanil
Autentimiseks kasutame tänase TARA teenuse testkeskkonda ja tema liidest. Paraku puudub võimalus klientrakenduse andmete edastamiseks GOVSSO teenuselt TARA teenusele.
Tulevaste lahendusvariantidena võib kaaluda TARA protokolli tagasiühilduvalt täiendada. Näiteks lisades mittekohustusliku klientrakenduse tunnuse parameetri GOVSSO → TARA suunalistesse päringutesse. Sellisel juhul tuleks päringu andmeid kaitsta muutmise eest allkirjastades päringu GOVSSO poolel. Lahendus eeldab tõenäoliselt TARA arendust, sest allkirjastatud päringute töötlemise tuge tänases TARA serveris ei ole. https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
Tegemist on erijuhtumiga, mille lahendamine POC-i skoobis ei oma suurt demonstratsiooni väärtust kuid teostus on tehniliselt keeruline.
Uue identsustõendi korral pikendatakse GOVSSO seansiküpsise kehtivust 15 minutini
Tehniline piirang valitud OIDC tarkvaras (ORY Hydra, vt Lisa 1). SSO seansiküpsise kehtivust ei saa väljastpoolt Hydra töövoogu muuta.
Valida mõni alternatiivne karbitoode või teostada ka Hydra poolt pakutav seansihalduse ja OIDC protseduurid rätseplahendusena. Eeliseks on täielik kontroll teenuse turvaprotseduuride üle (näiteks seansiküpsiste haldus, päringute valideerimise reeglid, jms).
Hydra serveri konfiguratsiooni kaudu pole võimalik juhtida SSO seansiküpsise kehtivust. GOVSSO protokolli analüüsis panime paika, et iga klientrakendus peab perioodiliselt teostama identsustõendi päringuid, et GOVSSO poolel seansi kehtivust pikendada. Hydra paraku sellist kasutusjuhtu ette ei näe. SSO seansiküpsis, mille Hydra seadmesse salvestab, kehtib kuni sirviku sulgemiseni või kui kasutaja nõustub välja logima kõikidest teenustest korraga.
Antud puuduse tulemusena pikeneb seansiküpsise lekkimise ajaaken. SSO POC-is tehtavate autentimiste ja väljalogimiste üle peetakse järjestust Hydra sisemiste andmeolemite kehtivuse abil (LoginRequest, ConsentRequest, LogoutRequest objektid). Paraku ei taga antud lahendus automaatset seansside aegumist GOVSSO poolel või puudub vastava protsessi kirjeldus Hydra toote dokumentatsioonis.
Hydra kasutamise korral GOVSSO taustsüsteemis tuleb täpselt rakendada seansi kehtivuse kontrolli Hydra sisemiste andmeolemite järgi. Kuigi SSO seansiküpsis seisab kasutaja sirvikus kauem kui 15 minutit, saab serveri poolelt SSO seansi lõpetamise teostada automaatse taustaprotsessi kaudu. Aegunud seansitunnusega küpsise lekkimine ei langeta GOVSSO üldist turvalisust.
SSO Seansi kestel autentimise taseme tõstmisel, tühistatakse kasutaja seansid kõikides klientrakendustes ja seadmetes
Hydra REST liides ei toeta seansi lõpetamist GOVSSO poolelt seadmepõhiselt. Seansi lõpetamine Hydra serveri poolel saab toimuda ainult isiku (subjekti) mitte seadme põhiselt.
Antud piirangu tõttu ei õnnestunud kasutaja jaoks mugaval viisil lahendada mitme paralleelse seadme kasutusjuhtusid. Näiteks olukorras, kus kasutaja on loonud SSO seansid mitmes seadmes võib ühes seadmes seansi automaatne lõpetamine esile kutsuda SSO seansi lõpetamise ka teises seadmes.
Mitte kasutada globaalse väljalogimise jaoks Hydra OIDC liidese väljalogimise URL-i ("OP initiated logout"). Selle asemel teostada Hydra sisemiste andmeolemite (ConsentRequest) tühistamine vastavalt konkreetse seadmega seotud SSO seansitunnusele. Soovitatavalt tuleks konsulteerida Hydra arendusmeeskonnaga, et leida korrektne lahendus tuvastamaks seadmega seotud SSO seansi väärtus Hydra administreerimise liidese kaudu.
Hydra administreerimise liides ei edasta eelmisel autentimisel tuvastatud isikuandmeid sso-login-rakendusele
Hydra REST liideses ei edastata uute autentimispäringute korral sama SSO seansiga seotud varasema autentimise andmeid sso-login-server rakendusele. Antud puuduse tulemusena ei ole login serveril piisavalt konteksti, et uue klientrakenduse jaoks täielikku identsustõendit koostada.
Antud puudusest möödapääsemiseks realiseeriti POC-i login rakenduses eraldiseisev autenditud isikuandmete salvestamine. sso-login-server salvestab iga unikaalse SSO seansi kohta viimase autentimise sündmusega saabunud isikuandmed, et neid iga järgneva sama SSO seansi raames tehtud autentimise päringu juures kasutada.
Hydra administreerimise liidese kaudu saab isiku tunnuse (subject) järgi pärida isiku eelnevad väljatatud load. Lubade nimekirja tuleks sorteerida selliselt, et leida ainult aktiivse seansi ja seadmega seotud load ja pärida lisa-isikuandmed eelneva loa objekti küljest. POC lahenduses salvestasime rakenduse lihtsustuse huvides isikuandmed eraldi mälus hoitavasse andmestruktuuri.
GOVSSO poolel on tarvis pidada arvestust SSO seansi raames loodud ja hetkel aktiivsete klientrakenduste seansside üle. Hydra REST liides võimaldab leida kõik SSO seansi raames isiku poolt antud volitused (ConsentRequest). Volituste objektid on seotud SSO seansiga klientrakenduse SSO seansitunnuse (sid väite) kaudu.
Paraku ei uuenda Hydra oma sisemises andmebaasis volituste nimekirja kui autentimise päringus pole määratud prompt=consent parameetrit. Järjestikuste SSO seansside korral ei teki Hydra seansihoidlasse uusi volituste objekte ja väljalogimise korral eemaldatakse seansi tunnused ka eelnevatelt objektidelt.
OIDC spetsifikatsiooni järgi on antud parameeter mittekohustuslik ja GOVSSO OIDC profiilis kohustuslik ainult SSO seansi uuendamise päringu korral. POC rakenduse realiseerimisel lisasime prompt=consent parameetri igale autentimise päringule, et Hydra sisemise töövooga kokku viia. Kui tulevases GOVSSO arendushankes on soov tingimata kasutada Hydra lahendust, siis võib kaaluda GOVSSO OIDC profiilis autentimise päringus prompt=consent parameetri kohustuslikuks muutmist. Praeguses GOVSSO protokolli versioonis selle parameetri kasutamist ei nõuta.
Vajab täpsemat analüüsi, kas tegemist on Hydra serveri oodatud käitumisega või veaga. Kui Hydra muutmine ei ole plaanis, siis võib kaaluda prompt=consent parameetri muutmist kohustuslikuks GOVSSO protokolli autentimise päringutes.