Sustav jedinstvene autentikacije korisnika (engl. single Sign-On, SSO) je autentikacijski mehanizam koji omogućuje da se korisnik u sustav prijavi samo jednom i nakon toga pristupa svim aplikacijama koje koriste SSO servis bez potrebe za ponovnim unosom korisničke oznake i zaporke.
Uporaba Single sign-On servisa znatno poboljšava doživljaj korisnika prilikom prijavljivanja u veći broj aplikacija, za prijavu u sve aplikacije korisnik rabi isti elektronički identitet.
Za implementaciju SSO funkcionalnosti u sustavu AAI@EduHr mogu se koristiti protokoli kao što su Security Assertion Markup Language (SAML) 2.0, Central Authentication Service (CAS) ili OpenID Connect (OIDC).
Prednosti SSO autentikacije
Za korisnike:
- manji broj vjerodajnica (korisničkih imena i lozinki) za zapamtiti
- manji broj autentikacijskih događaja prilikom pristupa uslugama (manji broj unosa vjerodajnica)
- pristup različitim uslugama pomoću istih vjerodajnica
Za davatelje usluga:
- delegiranje dijela poslova oko implementacije autentikacije (npr. implementacija ekrana za prijavu, validacija vjerodajnica, autentikacija korisnika, sigurno čuvanje korisničkih podataka i sl.)
- implementacija autentikacije po standardnim autentikacijskim protokolima
- korištenje različitih načina autentikacije korisnika (korisničko ime i lozinka, višestupanjska autentikacija...)
Sigurnosni apsekti:
- nema izlaganja korisničkih vjerodajnica usluzi kojoj korisnik želi pristupiti (autentikacija se događa kod davatelja elektroničkog identiteta)
Elektronički identitet
Identitet definiramo kao skup atributa (podataka) o pojedincu tj. ljudskoj osobi. Identiet može sadržavati podatke kao što su ime i prezime osobe, adresa prebivališta i slično.
Uz općenite atribute koji opisuju osobu, svaki identitet sadrži i neki atribut koji jedinstveno određuje osobu u nekom kontekstu. Takav atribut nazivamo identifikatorom. Neki primjeri identifikatora su OIB, JMBAG, broj osobne iskaznice, broj putovnice ili slično. Identifikatori imaju vrlo značajnu ulogu u sustavima za upravljanje identitetima te u postupcima autentikacije osobe.
Ako su podaci o identiteu dostupni u elektroničkom obliku, onda govorimo o elektroničkom identitetu.
U sustavu AAI@EduHr, elektronički identiteti nastaju na matičnim ustanovama, a spremljeni su u LDAP imenicima.
eduHr shema
U sustavu AAI@EduHr, atributi koji su dostupni o nekoj osobi definirani su eduHr shemom. To znači da su atributi propisani, tj. da imaju određenu semantiku i sintaksu. To olakšava njihovo korištenje jer davatelji usluga znaju koje podatke (i u kojem obliku) mogu očekivati o osobi.
Jedna osoba može imati više elektroničkih identiteta u različitim kontekstima. Na primjer, osoba može imati elektronički identitet u sustavu NIAS (nacionalni identifikacijski i autentikacijski sustav), u sustavu AAI@EduHr (identifikacijski i autentikacijski sustav znanosti i obrazovanja), te u bilo kojem drugom sustavu koji posjeduje podatke o osobi i nudi funkcionalnosti identifikacije i autentikacije.
Elektronički identitet vs. korisnički račun
Pojam "elektronički identitet" se ponekad zna pomiješati s pojmom "korisnički račun" (engl. account). Korisnički račun osobe tipično se odnosi na konstrukciju u nekoj usluzi tj. nekom informacijskom sustavu, servisu ili aplikaciji pomoću koje osoba obavlja radnje u samom sustavu / servisu / aplikaciji. Korisnički račun često sadrži podatke o osobi koji su preuzeti iz samog identiteta osobe, a tipično sadrži i dodatne podatke i identifikator(e) relevantne za sam sustav / servis / aplikaciju. Dakle, generalno govoreći, osoba će koristiti elektronički identitet prilikom autentikacije u uslugu, a usluga će osobu autorizirati te kreirati lokalni korisnički račun za obavljanje radnji u usluzi.
Općenito govoreći, osim za osobe identitet može biti vezan i za druge entitete kao što su uređaji, programski klijenti i slično. Na primjer, identitet za neki uređaj može sadržavati podatke kao što su naziv uređaja, model, verziju firmeware-a, neki identifikator kao što je neki nasumičan ID, IP adresa i slično. U određenim autentikacijskim protokolima predviđeno je i da takvi entiteti mogu obavljati postupke autentikacije na sličan način kao i osobe. U sustavu AAI@EduHr, elektronički identitet je uvijek vezan za osobu (student, učenik, zaposlenici na ustanovama) te postupak autentikacije obavlja sama osoba, tj. vlasnik elektroničkog identiteta (krajnji korisnik).
Federacija identiteta
Sustav AAI@EduHr često nazivamo federacijom identiteta u sustavu znanosti i obrazovanja, ili skraćeno AAI@EduHr federacijom.
Općenito govoreći, federacija identiteta (ili samo federacija) je skup organizacija koje dogovorno međusobno surađuju prema određenom skupu pravila. Pravila se obično sastoje od pravnih okvira, politika, tehničkih profila i standarda. U sklopu federacije, jedna od organizacija tipično ima i ulogu koordinator federacije, što znači da ona koordinira, održava i razvija sustav na tehničkoj i operativnoj razini. Svrha federacije je uspostava povjerenja između različitih dionika federacije te osiguravanje sigurne razmjene podataka o identitetu prilikom pristupa uslugama (autentikacije) unutar federacije.
Ustroj AAI@EduHr federacije reguliran je Pravilnikom, a poslove koordinacije, razvoja i održavanja sustava AAI@EduHr obavlja Srce - Sveučilišni računski centar Sveučilišta u Zagrebu.
Elementi federacije
Tipična federacija identiteta se sastoji od konceptualnih elementata kao što su davatelji elektroničkih identiteta, davatelji usluga te krajnji korisnici koji koriste dostupne usluge temeljem svoj elektroničkog identiteta.
Elementi AAI@EduHr federacije su:
- matične ustanove - davatelji elektroničkih identiteta, npr. sveučilišta, fakulteti, visoke škole, škole, znanstvene ustanove
- krajnji korisnici - vlasnici elektroničkog identiteta, npr. profesori, studenti, učenici, zaposlenici na ustanovi
- davatelji usluga (resursa) - matične ustanove ili partneri
- središnji AAI@EduHr servisi - posrednički sustav između korisnika, usluge i matične ustanove koji se koristi prilikom postupka autentikacije
Dakle, Matične ustanove u AAI@EduHr federaciji, uz ulogu davatelja elektroničkih identiteta, mogu imati i ulogu davatelja usluge. S druge strane, partneri AAI@EduHr federacije mogu imati samo ulogu davatelja usluge. Na primjer, partneri mogu biti komercijalne tvrtke koje nude usluge korisnicima u sustavu znanosti i obrazovanja.
Granice federacije
Tipičan način uspostave federacije identiteta u sustavima znanosti i obrazovanja (akademske federacije) je uspostava na nacionalnoj razini. Dakle. akademske federacije identiteta tipično djeluju unutar granica jedne države, pa se često nazivaju i nacionalnim akademskim federacijama.
Uz nacionalne federacije postoje i interfederacijski servisi koji omogućuju povezivanje postojećih nacionalnih federacija u konfederaciju. Članovi konfederacije (slično kao i članovi nacionalnih federacija) međusobno dogovorno surađuju na temelju skupa pravila i standarda koji osiguravaju interoperabilnost. Svrha konfederacije je osiguravanje pouzdane razmjene podataka vezanih uz identitet između federacija članica.
Jedan od takvih interfederacijskih sevisa eduGAIN, a cilj mu je omogućiti funkcionalnosti jedinstvene autentikacije na europskoj i globalnoj razini za članove akademske zajednice.
AAI@EduHr je punopravna članica eduGAIN-a od lipnja 2011. godine
Federacijski protokoli
Tehnički gledano, funkcioniranje federacije se temelji na korištenju otvorenih tehnologija, standarda, specifikacija i protokola. Koristeći otvorene tehnologije svi dionici federacije mogu postići interoperabilnost, povjerenje i ciljanu sigurnost.
Jedna od najpopularnijih tehnologija za uspostavu i funkcioniranje federacija je Security Assertion Markup Language (SAML). Protokol SAML je začetnik u definiranju i popularizaciji entiteta kao što su "davatelj identiteta" (engl. identity provider), davatelj usluge (engl. service provider), te u definiranju na koji način ostvariti povjerenje između njih razmjenom strukturiranih metapodataka. Uz to, definira i na koji način omogućiti jedinstvenu autentikaciju (engl. Single Sign-On, SSO) krajnjeg korisnika na uslugama, tj. definira siguran način isporuke autentikacijskih i autorizacijskih atributa kranjeg korisnika samoj usluzi. Pri tome davatelj identiteta i davatelj usluge mogu biti na različitim domenama.
Uz SAML, neki od drugih protokola za uspostavu i funkcioniranje federacija su obitelj protokola OpenID i WS-Federation.
Tipovi arhitekture federacije
Gledano kroz arhitekturu, federacije identiteta se obično dijele na mesh i hub-and-spoke tipove federacija.
Mesh arhitektura federacije
Mesh arhitektura je arhitektura u kojoj su sve komponente distribuirane na svakoj ustanovi koja sudjeluje u federaciji. Nema centralnog servisa koji prima autentikacijske zahtjeve i odgovara na njih, nego svaka ustanova ima svoj servis koji obavlja tu zadaću (uloga davatelja identiteta). Uz to, svaka ustanova može imati usluge koje pruža. Svi ti entiteti (davatelji identiteta i usluga) su popisani u katalogu (u SAML-u to je XML s metapodacima davatelja) koji je dostupan svim dionicima federacije. Dakle, taj katalog govori tko je tko u federaciji i koje funkcionalnosti pruža. Glavni izazov u mesh federacijama je upravljanje metapodacima i uspostava povjerenja svih entiteta u federaciji, određivanje koji atributi o osobi će biti dostupni kojim uslugama, te implementacija novih autentikacijskih protokola.
Hub-and-spoke arhitektura federacije
Hub-and-spoke tip arhitekture federacije se može implementirati na dva načina.
Prvi način je da se implementira središnji proxy servis koji sluša na autentikacijske zahtjeve i prosljeđuje ih određenoj ustanovi na obradu. Po vraćanju odgovora s autentikacijskog servisa na ustanovi, proxy prosljeđuje odgovor originalnom zahtjevatelju. Dakle. svaka ustanova i dalje ima servis koji obrađuje autentikacijske zahtjeve, samo što zahtjeve ne dobiva od različitih usluga, nego ih prosljeđuje središnji proxy. Zbog toga, servisi za autentikaciju na ustanovama (davatelji identiteta) moraju znati jedino za središnji proxy, jer jedino će od njega dobivati autentikacijske zahtjeve.. Sa druge strane, davatelji usluga moraju znati jedino za središnji proxy, jer jedino će njemu slati autentikacijske zahtjeve. Dakle, postojanje središnjeg proxy-a donekle pojednostavljuje uspostavu povjerenja. Nedostatak ovog tipa arhitekture je da ako se dogodi neki kvar na proxy-u, čitava federacija prestaje s radom. Drugi nedostatak je da je implementacija novih autentikacijskih protokola i dalje komplicirana jer ih je potrebno implementirati na svakoj ustanovi (davatelju identiteta). Prednost ovog tipa arhitekture je da korisnik unosi svoje vjerodajnice direktno na servisu svoje matične ustanove, a s druge strane proxy može kontrolirati koji atributi o osobi će biti dostupni uslugama te ih može po potrebi transformirati.
Drugi način implementacije hub-and-spoke arhitekture je implementacija središnjeg autentikacijskog servisa koji ima neki oblik pristupa bazi elektroničkih identiteta na ustanovi. Dakle, u ovom tipu arhitekture ustanove nemaju servis koji obrađuje autentikacijske zahtjeve, što implementaciju čini jednostavnijom. Korisnici unose svoje vjerodajnice na centralnom login servisu koji onda na neki način obavlja provjeru vjerodajnica na samoj ustanovi. Nedostatak ovog tipa arhitekture je da ako se dogodi kvar na centralnom login servisu, čitava federacija prestaje s radom. Prednost ovog tipa arhitekture je da centralni login servis predstavlja jedno mjesto uspostave povjerenja. te je implentacija novih autentikacijskih protokola jednostavnija (mora se implementirati samo na jednom mjestu, na centralnom login servisu).
Arhitektura federacije AAI@EduHr je hub-and-spoke s centralnim login servisom, a komunikacija s bazom elektroničkih identiteta na ustanovi obavlja se HTTPS / SOAP protokolom.
Autentikacija vs. autorizacija
Općenito govoreći, da bi osoba mogla pristupiti nekoj usluzi obično se mora autenticirati. Prilikom autentikacije, osoba unosi svoje vjerodajnice npr. korisničku oznaku i zaporku (ili dodatni podatak u slučaju višestupanjske autentikacije). Unesene vjerodajnice se provjeravaju u odnosu na prethodno registrirane podatke. Ako podaci odgovaraju, korisnik je autenticiran.
Nakon autentikacije, usluga tipično koristi (ili otvara) lokalni korisnički račun za osobu te obavlja postupak autorizacije kojim se definira što osoba može raditi u usluzi, odnosno koje privilegije osoba ima. Autorizacija se može obaviti na temelju podataka iz samog elektroničkog identiteta osobe ili se definira po korisničkom računu, ulozi u usluzi ili slično.
Sjednice (engl. sessions)
Nakon što se osoba autenticira u nekom sustavu, za nju se tipično otvara tkz. sjednica (engl. session). Pomoću sjednice sustav može pratiti je li korisnik autenticiran, kada se autenticirao, te neke druge podatke kao što je korisnička oznaka i slično. Na taj način, usluga ne mora za svaku radnju tražiti ponovnu autentikaciju i podatke iz identiteta. Uz to, sustav tipično ima postaveljno ograničenje trajanja sjednice, pa u slučaju isteka sjednice može tražiti korisnika ponovnu autentikaciju. Istek sjednice tj. ponovna autentikacija se obavlja kako bi se provjerilo da je "za ekranom" još uvijek ista osoba koja se prethodno prijavila.
Trajanje sjednice se razlikuje od sustava do sustava, a oblično ovisi o osjetljivosti radnji koje je moguće obaviti u sustavu. Na primjer, sustavi on-line bankarstva će tipično imati vrlo kratku sjednicu, na primjer trajanja nekoliko minuta, dok će neki drugi manje osjetljivi sustavi imati sjednicu od nekoliko sati, dana ili dulje.
Jedinstvena autentikacija (engl. Single Sign-On - SSO)
Najčešći slučaj upotrebe za koji se koristi SAML je međusobna jednokratna prijava,
prema našem iskustvu. U ovom scenariju korisnik treba pristupiti više aplikacija
koji se nalaze u različitim domenama, poput application1.com i application2.com.
Bez jednostruke prijave na više domena, korisnik će možda morati uspostaviti račun u svakoj
aplikacija i prijavite se u svaku aplikaciju pojedinačno. To znači potencijalno mnogo
različita korisnička imena i lozinke koje će korisnik pamtiti. Ako je korisnik pravno lice
SAML omogućuje aplikacije
za delegiranje provjere autentičnosti korisnika udaljenom entitetu poznatom kao davatelj identiteta. The
davatelj identiteta ovjerava korisnika i aplikaciji vraća tvrdnju s
informacije o ovjerenom korisniku i događaju ovjere. Ako korisnik pristupi
druga aplikacija koja delegira autentifikaciju istom davatelju identiteta,
korisnik će moći pristupiti drugoj aplikaciji bez b