[ARHIVEERITUD]

⚠ Dokumenti ei ajakohastata. Palume siinsele teabele mitte tugineda.

Seansihaldus

Eesmärk

Käesolevas juhendis selgitame, millised variandid seansihalduse lahendamiseks on olemas ja kuidas seansihalduse varianti valida. Lühidalt käsitleme ka seansihaldusega seotud turvaohte.

Selgitamine on vajalik, sest internetis leidub küll seansihalduse käsitlusi, kuid tavaliselt lähtuvad need kas konkreetsetest toodetest või erinevate arendajate harjumustest. Veebirakenduse all mõistame sirvikus kasutatavat, kuid ka serveripoolset töötlust omavat rakendust.

Juhendi sihtrühmaks on e-teenuseid kavandavad arhitektid.

Seanss ja selle haldus

Seanss on ajas piiratud suhe konkreetse kasutaja ja rakenduse vahel.

Seanss on seotud ka kasutaja seadmega, täpsemalt sirvikuga.

Seansihaldus peab tagama, et rakendus, eriti selle serveripool, teab, et sirviku taga on sama kasutaja, kes seansi loomisel autenditi.

Seansihaldus jaguneb:

Seonduvad teemad:

Seansiga koos kasutatakse mõistet (state). Eriti küsimuses, kummal pool (või mõlemal pool) olekut hoitakse. Seansi- e olekuvaba (sessionless, stateless) suhtlus on selline, kus suhet hoiab ülal ainult üks pool (klient s.t sirvik).

Seansi elukaar

Seansi loomine

Seanss luuakse vahetult kasutaja autentimise järel. Autentimisteenuse TARA kasutamisel on autentimise tulemuseks:

Konkreetne tegevus sõltub valitud seansihalduse skeemist (vt allpool).

Seansi kontrollimine

Seansi kontrollimise vajadus tuleneb sellest, et veebirakendus on hajusrakendus. Veebirakendusel on kaks osa:

Sirvik ja server suhtlevad üksteisega peamiselt HTTP protokolli alusel, päring-vastus režiimis. Erandid: server push tehnoloogia, WebRTC protokoll.

Seanss hõlmab enamat kui üht päring-vastus suhtlusakti. Seetõttu on vaja kontrollida, kas suhtluspartner on ikka sama. Serveril on püsiv identiteet - DNS domeeninime sisaldav URL. Sirvikul - ja seda kasutaval kasutajal - sellist püsiidentiteeti ei ole. Sirvikupoole identiteet luuakse kasutaja autentimisega. Server väljastab sirvikule seansitõendi (session token). Igal järgmisel pöördumisel esitab sirvik seansitõendi. Server peab kontrollima, et tõend on õige ja kehtiv.

Seansihalduse kontekstis on olulised ka sirviku päringud teistel aadressidel, kui allikaadress, asuvate ressursside laadimiseks. Need päringud jagunevad:

Sirvik saab teha AJAX-päringuid ka oma allikaadressi s.t oma serveri poole.

Seansi aegumine

Server ei saa vahetult kontrollida, kas (sama) kasutaja on veel arvuti taga. Seetõttu on levinud praktika seada seansile aegumisajad. Tüüpiliselt:

Aegumisajad määratakse rakenduse seadistuses. Teaduslikult põhjendatud soovitusi aegumisaegade määramiseks ei ole teada.

Seansi pikendamine

Seansi aegumisel võib rakendus anda kasutajale võimaluse seanssi pikendada. Seda võib teha:

Seansi lõpetamine

Seansi lõpetamine võib toimuda kas kasutaja või serveri algatusel. Seansi lõpetamise viis sõltub valitud seansihalduse skeemist.

Sirviku poolelt võib seansi lõpetamine toimuda:

Seansi lõpetamine võib olla raskem kui seansi alustamine. Seda mitmel põhjusel:

Nii võib tekkida olukord, kus osapoolte arusaamine seansi kehtivusest erineb. Hajussüsteemis ei saagi sellist võimalust täielikult välistada.

Seansi puhverdamine

Siin peame silmas sotsiaalvõrkude poolt laialt kasutatud praktikat, kus seanssi ei lõpetata sirviku sulgemisega. Sirvikut uuesti avades on kasutaja taas sisse logitud. Tehniliselt tehakse seda seansitõendi panemisega küpsisesse, mida sirviku sulgemisel ei kustutata.

Ühekordne sisse- ja väljalogimine (SSO)

Ühekordse sisselogimise korral saab kasutaja - nagu nimigi ütleb - ühe autentimisega sisse logida mitmesse rakendusse. Tehniliselt tehakse see nii, et SSO teenus teeb kasutajaga seansi - seda nimetatakse SSO seansiks. Lisaks on igal rakendusel kasutajaga oma seanss. Rakendusse sisselogimisel kontrollitakse, kas kasutajaga on loodud SSO seanss. Kui jah, siis uuesti autentimist ei tehta.

Ühekordse sisselogimise juures ei ole kõige raskem mitte tehniline keerukus, vaid tagamine, et kasutaja saab aru, kuhu ta on või ei ole sisse (või välja) loginud. Ühekordne väljalogimine (single sign-off) tähendab seda, et kasutaja saab ühe väljalogimisega kõigist rakendustest välja logitud. Kõik vastavad seansid tuleb lõpetada. See on keerukas.

Ühekordset väljalogimist saab teostada nii, et iga rakendus käib kasutaja iga pöördumise korral SSO serverilt küsimas, kas SSO seanss kehtib. See võib olla võrgule koormav ja on keskseks nuripunktiks (single point of failure).

Ühekordset sisselogimist saab kasutada ka ilma ühekordse sisselogimiseta. Sellisel juhul peab iga rakendus oma seansi pidamise ja lõpetamise eest ise hoolt kandma.

Seansi “üleandmine”

Seansi üleandmise all mõistetakse autentimise tulemuse edasiandmist teisele rakendusele. Nt kasutaja logib sisse teabeväravasse eesti.ee, logib seal sisse ja suunatakse teise e-teenusesse. Hea oleks, kui teises teenuses ei peaks uuesti sisse logima. Seansi “üleandmine” on võimalik, kuid seda ei tohi teha seansitõendit lihtsalt kasutajale kaasa pannes. Tuleb läbi teha nonssi sisaldav voog.

Seansihalduse skeemi valik

Seansihalduse lahendamiseks on u 4-5 levinud skeemi.

Valikukohad

Seansihalduses tuleb konkreetses sirvikus töötav konkreetne kasutaja siduda rakendusega. Tavaliselt tehakse seda seansiga üksüheselt seotud identifikaatori või tõendi (token) abil. Valikukohad on:

Need valikud koos määravad seansihalduse skeemi.

Traditsiooniline skeem (juhusõne küpsises)

Veebitõend küpsises

Erineb traditsioonilisest meetodist selle poolest, et:

Veebitõend sirvikupoolses seansihoidlas (Session Storage)

Erinevus eelnevast on selles, et:

Tühistusnimekirja kasutamine

Tühistusnimekirja pidamine on otstarbekas siis, kui tahetakse teostada väljalogimise funktsionaalsus. Kui rahuldab ka veebitõendi aegumine või sirvikus saki sulgemine (sirvikupoolse seansimälu kasutamisel), siis ei ole tühistusnimekirja vaja.

Skeemi valimine

Seansihalduse skeem tuleks valida lähtudes:

SSO kasutamise kaalumisel tuleks hinnata, kas ühekordne sisse- ja väljalogimine üldse sobib rakenduste kasutusmustrisse.

Ohud

Peamised ohud on:

Ohtudeks võib lugeda ka:

Need viimased on sellised, mille vastu ei ole kaitset (“all bets are off”). Tavaliselt välistatakse ka ohud:

Koodisüsti ohtu peetakse suhteliselt suureks.

Riigi Infosüsteemi Amet · 2017-2021 · https://github.com/e-gov/TARA-Doku