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, jer 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). Više informacija o AAI@EduHr sustavu jedinstvene autentikacije korisnika možete pronaći u prezentaciji AAI@EduHr SSO rješenje za autentikaciju krajnjih korisnika(link is external).
Da bi aplikacija mogla koristiti AAI@EduHr SSO, potrebno je provesti registriraciju resursa u sustavu AAI@EduHr pomoću Registra resursa.
Otvaranje korisničkog računa u Registru resursa
Registracija novog resursa u sustavu AAI@EduHr, ažuriranje postavki resursa ili brisanje resursa obavlja se kroz web-aplikaciju Registar resursa.
Pristup Registru resursa dozvoljen je isključivo ovlaštenim predstavnicima davatelja usluga u sustavu AAI@EduHr. Davatelji usluga u sustavu AAI@EduHr mogu biti matične ustanove u sustavu AAI@EduHr ili partneri AAI@EduHr federacije.
Ako ste ovlašteni predstavnik davatelja usluge, trebate se registrirati (otvoriti korisnički račun) u Registru resursa nakon čega će administrator AAI@EduHr autorizirati vaš korisnički račun za puni pristup aplikaciji. Prvi korak je prijava u Registar resursa korištenjem AAI@EduHr elektroničkog identiteta ili neke od vjerodajnica kreiranih na društvenim mrežama (Facebook, Google, LinkedIn, Twitter). Gumb za prijavu nalazi se na desnom kraju navigacijske trake:
Na sljedećoj stranici potrebno je odabrati vjerodajnicu za prijavu:
Sljedeći korak registracije korisnika je popunjavanje postavki korisničkog profila. U polju Svrha registracije važno je navesti opravdan razlog potrebe korištenja Registra kako bi administrator sustava AAI@EduHr bio siguran da je korisnik dobro upoznat sa svrhom i namjenom Registra resursa te ga namjerava koristiti u smislene svrhe.
Po kliku na gumb "Spremi", vaš korisnički profil će biti zapamćen i postupak registracije dovršen, o čemu će biti obaviješteni administratori sustava AAI@EduHr. Na temelju informacija iz vašeg profila vašem će korisničkom računu naknadno biti omogućena (ili odbijena) autorizacija za puni pristup i korištenje Registra, o čemu ćete biti obaviješteni elektroničkom poštom.
Što je resurs?
Resurs je entitet u sustavu AAI@EduHr koji, osim što sadrži osnovne podatke o aplikaciji/usluzi koja koristi sustav AAI@EduHr, obuhvaća i aktivne konfiguracije svih autentikacijskih mehanizama kojima se navedena aplikacija/usluga služi u sustavu. Resurs se dakle sastoji od Općih podataka i autentikacijskih modula. U prvu skupinu spadaju općenite informacije poput naziva, opisa i vrste resursa skupa s nazivom ustanove s kojom je resurs povezan i pripadajućim kontaktima za podršku. Svaki resurs, da bi bio aktivan i funkcionalan, mora imati pridružen najmanje jedan od dostupnih autentikacijskih modula. Autentikacijski modul je segment koji sadrži skup konfiguracijskih parametara za CAS, SAML, OIDC, FWS ili RADIUS protokol. Svaki resurs može imati najviše po jedan aut. modul za pojedinačnu vrstu autentikacije putem jednog od navedenih protokola, no autentikacijski mehanizmi time nisu ograničeni svaki na samo jedan poslužitelj. U svakom modulu može se uključiti više autentikacijskih poslužitelja s kojima aplikacija/usluga komunicira koristeći iste konfiguracijske parametre koje taj modul definira.
Postavljanje zahtjeva za registraciju resursa
S autoriziranim pristupom u Registar resursa imate pravo kreirati zahtjeve za registraciju novih, te mijenjanje ili brisanje postojećih resursa čiji ste administrator. Na navigacijskoj traci nalazi se poveznica za pregled postojećih resursa (Resursi) te poveznica do forme zahtjeva za registraciju novog resursa (Registracija resursa). Ako još za nijedan resurs niste navedeni kao administrator, popis sa prve poveznice bit će prazan. Kliknite na poveznicu Registracija resursa i otvorit će se forma za unos općih podataka. Detaljniji opis te forme nalazi se u nastavku.
Opći podaci resursa
Na vrhu forme za unos općih podataka o novom resursu nalazi se kvadratić s naslovom "Kao administrator usluge potvrđujem da će usluga biti pružana sukladno odredbama Pravilnika o ustroju AAI@EduHr". U kvadratić trebate staviti kvačicu kako biste potvrdili da prihvaćate uvjete korištenja AAI@EduHr infrastrukture definirane Pravilnikom o ustroju autentikacijske i autorizacijske infrastrukture sustava znanosti i visokog obrazovanja u Republici Hrvatskoj.
U sljedećem nizu polja potrebno je unijeti podatke koji će u najvećoj mjeri biti javno dostupni korisnicima na stranici Aplikacije koje koriste sustav AAI@EduHr te je stoga bitno da podaci budu što jasniji i informativniji.
Naziv resursa i opis resursa mogu biti proizvoljni, no bitno je da krajnji korisnici iz naziva i opisa mogu nedvojbeno shvatiti koja je točna namjena resursa.
Osim ako se ne radi o nekoj već isprobanoj aplikaciji, za svaki novi resurs u sustavu AAI@EduHr koji je u fazi razvoja i testiranja u polju Vrsta resursa treba postaviti vrijednost "Test". Autentikacija za resurse koji su u fazi razvoja vrši se putem testne AAI@EduHr SSO infrastrukture čiji parametri su dostupni na web stranici AAI@EduHr Lab.
U padajućem izborniku Matična ustanova s kojom je resurs povezan potrebno je odabrati odgovarajuću matičnu ustanovu, osim u slučaju kad je resurs vezan za Partnera federacije. Tada je umjesto prvog obavezan drugi padajući izbornik: Partner federacije s kojim je resurs povezan. Izbor Globalne usluge s kojom je resurs povezan nije obavezan.
U polje URL sjedišta usluge treba unijeti adresu početne stranice aplikacije na kojoj se nalazi gumb/poveznica za prijavu korisnika potem sustava AAI@EduHr.
Ako postoji URL na kojem je dostupan logotip usluge, u polje treba unijeti direktan URL do datoteke logotipa. Preostala dva polja je potrebno popuniti ako postoje traženi podaci.
U odjeljku Kontakti trebate unijeti podatke najmanje po jednog kontakta za svaku od sljedeće tri kategorije:
- Podrška korisnicima
- Tehnička podrška
- Voditelj usluge
Podaci o voditelju proizvoda i tehničkoj podršci koriste se isključivo interno, tj. služe AAI@EduHr timu kao kontakt podaci u slučaju da se pojavi nekakav problem s aplikacijom.
Podaci o službi koja bi trebala pružati podršku krajnjim korisnicima dostupni su javno, tj. prikazuju se nakon što korisnik odabere odgovarajući resurs na popisu produkcijskih resursa dostupnom na web stranici Aplikacije koje koriste sustav AAI@EduHr.
Pri dnu forme za unos općih podataka nalazi se tablica s popisom svih osoba koje su evidentirane u bazi Registra resursa. Ako želite da još netko osim vas ima mogućnost ažuriranja podataka o resursu, označite te osobe dodavanjem polja i odabirom tih osoba s liste.
Klikom na gumb Zatraži registraciju na dnu forme poslat ćete zahtjev. Čim to učinite trebate nastaviti i odabrati odgovarajući autentikacijski modul novoga resursa. Upute za taj dio slijede u nastavku.
Odabir autentikacijskog modula
Svaki funkcionalan resurs mora imati najmanje jedan pridruženi autentikacijski modul. Ako se radi o novom resursu za kojega je netom kreiran zahtjev s općim podacima za registraciju, na stranici resursa će se, uz karticu "Opći podaci" nalaziti nova kartica Odabir autentikacijskog modula.
U slučaju da se radi o resursu s pridruženim nekim autentikacijskim modulom, a koji nema već pridružene sve vrste aut. modula, kartica Dodaj modul nalazit će se izdvojena uz desni rub stranice.
CAS konfiguracija
Ako odaberete modul za CAS autentikaciju, dobit ćete sljedeću formu:
Parametri CAS konfiguracije obuhvaćaju:
- Atribut koji će se isporučuje kao jedinstveni identifikator korisnika
- Izbor isporuke svih korisničkih atributa
- Popis URL-ova poslužitelja s kojeg stižu autentikacijski zahtjevi - moguće je dodavanje polja te višestruki unos URL-ova klikanjem na gumb '+'
SAML konfiguracija
Nakon odabira za unos SAML konfiguracije, korisnik dobiva formu koja se sastoji od:
- Općih postavki:
- AuthService - Autentikacijski servis koji aplikacija koristi
- AttributeMapping - Shema po kojoj se mapiraju atributi
- ValidateAuthnRequest - Ovjeravanje autentikacijskog zahtjeva
- ValidateLogoutRequest - Ovjeravanje odjavnog zahtjeva
- NameIDAttribute - Atribut koji se koristi za generiranje parametra "nameID"
- NameIDFormat - Format parametra "nameID"
- NameIDEncryption - Kriptiranje parametra "nameID"
- EncryptAssertion - Kriptiranje dijela autentikacijskog odgovora koji sadrži korisničke podatke
- RedirectValidate - Ovjeravanje zahtjeva za preusmjeravanje
- ForceAuthn - Zahtijevanje autentikacije prilikom svake prijave (ignoriranje SSO sjednice)
- SignAssertion - Digitalno potpisivanje dijela autentikacijskog odgovora koji sadrži korisničke podatke
- SignResponse - Digitalno potpisivanje autentikacijskog odgovora
- SignLogout - Digitalno potpisivanje zahtjeva za odjavu
- IdpCertFile - Datoteka koja sadrži certifikat davatelja identiteta
- SpCert - Certifikat (javni ključ) davatelja usluge
- Postavki za SAML metapodatke:
- EntityID - Jedinstveni identifikator resursa jednoznačno određuje vašu aplikaciju na razini AAI@EduHr federacije.
- AssertionConsumerService URL - Adresa na koju sustav jedinstvene autentikacije preusmjerava korisnikov web preglednik nakon uspješne autentikacije.
- SingleLogoutService URL - Adresa na koju sustav jedinstvene autentikacije preusmjerava korisnikov web preglednik nakon uspješne obrade zahtjeva za odjavu
- Popisa za odabir korisničkih atributa koje sustav po uspješnoj prijavi isporučuje aplikaciji koja koristi resurs (potrebno je željene atribute preseliti iz lijevog u desni popis klikom na svakog od njih)
Pri svakom odabiru novog atributa, u nižem odjeljku naslovljenom "Namjena odabranih atributa" pojavljuje se odgovarajuće polje za opis njegove namjene. Ova polja su obavezna i u njima je potrebno kratko i precizno opisati na koji način web-aplikacija, odnosno ustanova namjerava koristiti svaki odabrani atribut. Popis atributa skupa s opisima njihove namjene naći će se na stranicama za informiranje o web-aplikacijama koje se nalaze u sustavu AAI@EduHr i bit će vidljiv svim korisnicima u sustavu AAI@EduHr.
Dozvoljeno je označiti isključivo one atribute koji su potrebni za funkcioniranje vaše aplikacije. Ako se naknadno pokaže da sustav AAI@EduHr vašoj aplikaciji treba isporučivati i još neke dodatne atribute, isporuku dodatnih atributa možete postaviti u zahtjevu za izmjenu SAML konfiguracije klikom na gumb Uredi u kartici "SAML konfiguracija" na stranici resursa.
Važno je napomenuti da su pojedini atributi u sustavu AAI@EduHr opcionalni. Ovisno o tome je li za neki atribut unesena vrijednost ili ne, sustav AAI@EduHr može ili ne mora isporučiti te atribute. Također, atributi u podskupini Lokalni atributi ustanove su specifični za domenu skole.hr i druge ustanove u sustavu AAI@EduHr ih ne koriste. Više informacija o standardnim atributima koje sustav AAI@EduHr može isporučiti vašoj aplikaciji možete pronaći na web stranici hrEdu imeničke sheme.
Ovisno o programskom jeziku u kojem je vaša aplikacija napisana, vrijednosti navedenih parametara za SAML metapodatke možete pronaći u odgovarajućoj konfiguracijskoj datoteci ili na određenoj web adresi:
Ako je vaša aplikacija napisana u programskom jeziku PHP, tj. ako kao autentikacijski modul koristite simpleSAMLphp instaliran i iskonfiguriran prema uputama za implementaciju AAI@EduHr SSO mehanizma u PHP ailikacijama, vrijednosti parametara entityID, assertionConsumerService i singleLogoutService možete pronaći preko simpleSAMLphp administratorskog sučelja kao što je opisano u odjeljku Registracija novog resursa u sustavu AAI@EduHr;
- Ako vaša aplikacija kao autentikacijski modul koristi OIOSAML.NET instaliran i iskonfiguriran sukladno uputama za implementaciju AAI@EduHr SSO mehanizma u .NET ailikacijama, parametre entityID, AssertionConsumerService Location i SingleLogoutService Location možete pronaći u datoteci metadata.ashx koja se spominje u 13. koraku;
- Ako koristite Python/Django i SSO autentikaciju ste implementirali prema uputama na web stranici https://gist.github.com/darbula/5003f1d2e1528b089b30(link is external), vrijednosti parametara entityid, assertion_consumer_service, single_logout_service navedene su u datoteci settings.py;
Moguće je za resurs unijeti više skupina parametara za SAML metapodatke klikanjem na gumb '+'.
OIDC konfiguracija
Forma za unos OIDC konfiguracije podijeljena je na:
- Opće postavke:
- Client ID
- Secret - Tajni ključ klijenta
- Client Type - Naznaka je li klijent povjerljiv (eng. confidential) ili javan (eng. public)
- Lokacije za preusmjeravanje (redirectURI) - popis lokacija u URI formatu (moguće je dodavanje polja te višestruki unos URI-jeva klikanjem na gumb '+')
- Popis za odabir opsega (eng. scopes), tj. skupova tvrdnji (eng. claims) koje u sustavu AAI@EduHr predstavljaju korisnički atributi. Atribute po uspješnoj prijavi korisnika sustav AAI@EduHr prosljeđuje aplikaciji koja koristi resurs. Željene opsege je potrebno kliknuti kako bi se preselili iz lijevog u desni popis odabranih.
Slično kao kod SAML konfiguracije, pri svakom odabiru novog opsega, u nižem se odjeljku naslovljenom "Namjena odabranih atributa" pojavljuju polja za upis namjene atributa. Svaki opseg obuhvaća jednu ili više tvrdnji od kojih se svaka u sustavu AAI@EduHr predstavlja odgovarajućim korisničkim atributom. Kao i kod SAML konfiguracije, polja za opis namjena atributa su obavezna. Potrebno je dakle kratko i precizno opisati na koji način web-aplikacija, odnosno ustanova namjerava koristiti svaki odabrani atribut. Ove definicije namjena moraju biti točne jer će se dati na javni uvid korisnicima da ih se informira o tome na koji način se koriste njihovi osobni podaci.
Podrobniji opisi svih parametara iz OIDC konfiguracije nalaze se u uputama za implementiranje OIDC autentikacije, u poglavlju "Registar resursa":
Objašnjenje opsega i tvrdnji nalaze se na istoj stranici u poglavlju "Opsezi i tvrdnje":
RADIUS konfiguracija
Kod odabira konfiguracije za RADIUS modul dobivamo sljedeću formu za unos postavki RADIUS poslužitelja:
- Red - Red poslužitelja: primarni ili sekundarni
- serverIP - IP adresa RADIUS poslužitelja koji šalje upite
- serverPort - Port RADIUS poslužitelja (zadano: 1812)
- requestTimeout - Maksimalno vrijeme čekanja na odgovor (zadano: 5000)
- retries - Maksimalan broj ponavljanja upita (zadano: 0)
- sharedSecret - Javni ključ (ostavite neispunjeno)
Moguće je dodati više RADIUS poslužitelja za resurs klikanjem na gumb '+'. Na popisu se mora uvijek nalaziti jedan primarni poslužitelj, dok su svi ostali sekundarni.
Postupak odobravanja i obrade zahtjeva
U Registru resursa postoji nekoliko vrsta zahtjeva koji korisnik može postavljati nad pojedinim resursom. To su:
- Zahtjev za registraciju resursa
- Zahtjev za brisanje resursa
- Zahtjev za izmjenu Općih podataka resursa
- Zahtjev za dodavanje nekog od dostupnih autentikacijskih modula resursu
- Zahtjev za izmjenu konfiguracije nekog od pripadajućih autentikacijskih modula
- Zahtjev za brisanje nekog od pripadajućih autentikacijskih modula resursa
Prva dva tipa zahtjeva odnose se na resurs kao cjelinu skupa sa aut. modulima, ako postoje. Primjerice, zahtjev za brisanje resursa podrazumijeva automatsko brisanje i svih njegovih modula. Ostale vrste zahtjeva odnose se na dijelove resursa; konkretno na njegove Opće podatke ili autentikacijske module pojedinačno.
Kad autorizirani korisnik (odnosno administrator resursa) postavi neki od navedenih zahtjeva, o njegovom postavljanju obaviještavaju se odgovorne osobe ustanove za koju je resurs vezan (postavka "Matična ustanova s kojom je resurs povezan" u Općim podacima) i administratori sustava AAI@EduHr. Svaki se zahtjev, dakle, šalje na uvid odgovornoj osobi matične ustanove i na razmatranje administratoru AAI@EduHr. Da bi administrator AAI@EduHr prihvatio i proveo zahtjev nad resursom, zahtjev mora:
- biti ispravan
- imati odobrenje odgovorne osobe
Opis postupka odobravanja i provedbe zahtjeva za registraciju resursa s pripadajućim aut. modulom koje ste kreirali u prethodnim koracima ovih uputa slijedi u nastavku.
Napomena: U slučaju da je resurs povezan s partnerom federacije (umjesto s matičnom ustanovom sustava AAI@EduHr) ili da je autorizirani korisnik/administrator resursa ujedno i odgovorna osoba mat. ustanove, intervencija odgovorne osobe kao i slanje obavijesti u tu svrhu se ne izvode u postupku provedbe zahtjeva nad resursom.
Ako ste ispunili odgovarajuće forme za registraciju resursa i dodavanje aut. modula te poslali zahtjeve klikom na gumb Zatraži... na svakoj od njih, obavijesti o pojedinom zahtjevu poslane su putem elektroničke pošte na adrese odgovornih osoba i administratora AAI@EduHr. Na dnu stranice s prikazom resursa za administratora stoji obavijest "Zatražene radnje čekaju odobrenje odgovorne osobe matične ustanove."
Kad se odgovorna osoba prijavi u Registar resursa i otvori istu stranicu, na dnu će joj stajati prikazana kratka uputa i gumb Odobravam postupak.
Ako je pregledala sve zatražene radnje nad resursom te je sa svima njima suglasna, odgovorna osoba treba kliknuti na spomenuti gumb i time će odobriti sve zahtjeve. Nakon toga, na stranici se administratoru resursa prikazuje obavijest "Zatražene radnje su odobrene i čekaju obradu kod administratora AAI@EduHr."
Sad na red dolazi administrator AAI@EduHr koji još jednom provjerava unesene podatke. Ako je sve u redu, administrator AAI@EduHr će prihvatiti zahtjeve i provesti kompletan postupak (sve zatražene radnje) nad resursom. U slučaju da postoje neki nedostaci, administrator će ispravne zahtjeve provesti, a one s greškom odbiti uz obrazloženje koje će biti prikazano na stranici kako biste nedostatke mogli otkloniti. O uspješnom zaključenju postupka, odnosno o odbijenim zahtjevima bit ćete obaviješteni putem elektroničke pošte.
Napomena: autentikacija s novounesenim postavkama proradit će u roku od najviše pet minuta od trenutka provedbe zatraženih zahtjeva.
Objašnjenje boja i indikatora statusa resursa
Aplikacija Registra resursa na više mjesta koristi kombinacije ikona, boja i specifičnih izraza kako bi korisniku prenijela bitne informacije kroz što jednostavnije sučelje. Stranica s prikazom resursa sastoji se od nekoliko cjelina koje svojim izgledom i sadržajem upućuju na određeno stanje u kojem se resurs nalazi. Na samom vrhu je glavni naslov s imenom resursa ispisanim velikim tekstom. Ispod njega je pozicija rezervirana za poruke koje se odnose na resurs u cjelini, dok je niže, u prostoru za sadržaj otvorene kartice pozicija na kojoj se pojavljuju upozorenja vezana uz segment koji prikazuje otvorena kartica (Opći podaci ili neki od autentikacijskih modula).
Pozadinska boja oko imena resursa upućuje na to je li resurs aktivan i postoji li neki otvoreni zahtjev nad njime ili ne. Ako je pozadina siva, resurs je neaktivan. U tom slučaju uobičajeno na stranici stoji i dodatna obavijest zašto je to tako te što treba napraviti da bi se problem riješio. Žuta pozadina upozorava da je nad resursom otvoren jedan ili više zahtjeva, tj. da se nad njime vodi neki postupak. Tamnoplava pak znači da je resurs aktivan te da nema otvorenih zahtjeva nad njime; to je dakle stanje u kojem nikakva akcija nije potrebna. Primjer prikaza aktivnog resursa bez otvorenih zahtjeva nalazi se na slici:
U slučaju da nad resursom postoje otvoreni zahtjevi, kartica segmenta na koji se pojedini zahtjev odnosi prikazuje poruku s opisom zatražene radnje. Također, uz naslov te kartice je i ikona vezana uz vrstu radnje:
- zvjezdica (
): registracija/dodavanje - ključ (
): modifikacija - minus (
): brisanje
Kad administrator AAI@EduHr zbog uočene pogreške odbije zahtjev, resurs zadržava žutu boju jer taj zahtjev i dalje postoji, tj. čeka da korisnik koji ga je kreirao ispravi grešku. Poruka na razini cijelog resursa upozorava da je odbijen jedan ili više zahtjeva. Da bismo ga lakše pronašli, njegova kartica ima ikonu uskličnika ( 
) u naslovu. Kad je otvorimo, u njoj ćemo uočiti upozorenje narančaste boje koje uz radnju koja je odbijena navodi i obrazloženje (ako ga je administrator naveo prilikom odbijanja):
Napomena: upozorenja narančaste boje upućuju na pogrešku ili propust korisnika.
U popisu resursa izlistani su svi resursi kojima je korisnik administrator ili su vezani za matičnu ustanovu za koju je korisnik odgovorna osoba u sustavu AAI@EduHr. Popis resursa podijeljen je na dvije kartice od kojih jedna prikazuje aktivne, a druga neaktivne resurse. Resurs je aktivan ako je registriran te ima najmanje jedan pridružen autentikacijski mehanizam (modul) koji je u funkciji.
U svakom od stupaca koji predstavljaju autentikacijske module trenutno dostupne u Registru resursa nalazi se ikona-indikator njihovog statusa. Postoje četiri vrste indikatora:
- zelena kvačica (
): označava da je modul aktivan - smeđa kvačica (
): označava da je modul aktivan, no nad njim je otvoren zahtjev - sivi križić (
): označava da nema aktivnog modula - smeđi križić (
): označava da nema aktivnog modula, no otvoren je zahtjev za njegovo dodavanje
Klikanje bilo gdje u retku otvorit će stranicu s prikazom pojedinosti o resursu i pripadajućim modulima.
Kao što je već spomenuto, resurs je neaktivan ako još nije registriran ili ako nema pridružen funkcionalni autentikacijski modul. U stupcu Stanje u kartici s neaktivnim resursima evidentiramo tri tipa statusa u kojim resurs vodimo kao neaktivan:
-
nedostaje autentikacijski mehanizam - zatražena je registracija resursa, no uz nju još nije zatražen autentikacijski modul -
registracija resursa čeka odobrenje - zatražena je registracija resursa skupa s aut. modulom, no postupak još nije odobren i proveden - autentikacijski modul čeka aktivaciju - resurs je registriran, no postojeći zahtjev za dodavanje aut. modula još nije odobren i proveden
Ako kliknemo na resurs koji čeka registraciju, ali mu nedostaje zahtjev za dodavanje aut. modula, otvorit će se prikaz sličan ovome:
Odmah ispod imena resursa stoji obavijest da je uz zahtjev za registraciju potrebno dodati još i zahtjev za autentikacijski modul.
SAML konfiguracija za višestupanjsku autentikaciju
U sustavu AAI@EduHr moguće je registrirati uslugu koja će za prijavu korisnika koristiti višestupanjsku autentikaciju, gdje prvi stupanj predstavlja korištenje AAI@EduHr korisničke oznake i zaporke, a drugi stupanj korištenje jednokratnih tokena.
Trenutno podržani sustavi koji generiraju jednokratne tokene su:
- OTP (One Time Password) via SMS (uz korištenje mobilnog telefona korisnika) - korisnik upisuje token kojeg dobiva putem SMS-a na registirani telefonski broj
- Yubico Yubikey (https://www.yubico.com(link is external)) uređaj (kojeg korisnik mora posjedovati) - korisnik prenosi token putem Yubikey uređaja
- TOTP (Time-based One Time Password) uz korištenje posebne aplikacije (npr. Google Authenticator, FreeOTP ili OpenOTP) koju korisnik mora instalirati na svoje računalo - korisnik upisuje token koji mu je izgenerirala aplikacija (temeljem registriranog tajnog ključa).
Napominjemo kako autentikaciju putem tokena poslanog SMS-om (OTP via SMS) smatramo namanje sigurnom (u odnosu na ostale raspoložive sustave odnosno metode). Osim toga, za potrebe produkcijskog rada, usluga treba osigurati odgovarajući SMS gateway odnosno podmiriti troškove njegovog rada.
U svrhu registracije usluge koja će za prijavu korisnika koristiti višestupanjsku autentikaciju potrebno je slijediti poveznice u nastavku:
- Postavljanje zahtjeva za registracijom novog resursa (Aplikacija koja će za prijavu korisnika koristiti višestupanjsku autentikaciju treba biti registrirana u Registru resursa isključivo kao nova usluga u sustavu AAI@EduHr)
- Opći podaci
- Odabir autentikacijskog modula (SAML).
Kod odabira konfiguracije za SAML modul dobivamo sljedeću formu za odabir postavki za višestupanjsku autentikaciju pri čemu za AuthService iz padajućeg izbornika odabiremo Servis za multifaktorsku autentikaciju.
Nakon što smo za AuthService odabrali Servis za multifaktorsku autentikaciju, prikazuje nam se forma za odabir MFAType-a.
Sustav višestupanjske autentikacije putem atributa mfa_type vraća informaciju o vrsti drugog stupnja koji je korišten za autentikaciju.
Prednosti SSO autentikacije
Za korisnike:
- manji broj vjerodajnica (korisničkih imena i zaporki) 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 zaporka, višestupanjska autentikacija...)
Sigurnosni aspekti:
- nema izlaganja korisničkih vjerodajnica usluzi kojoj korisnik želi pristupiti (autentikacija se događa kod davatelja elektroničkog identiteta)
| Table of Contents |
|---|
Elektronički identitet
Identitet definiramo kao skup atributa (podataka) o pojedincu tj. ljudskoj osobi. Identitet 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.
| Info |
|---|
Ako su podaci o identitetu 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.
| Info |
|---|
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. |
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.
Elektronički identitet naspram korisničkih računa
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.
| Info |
|---|
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 firmware-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 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 koordinatora 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.
| Info |
|---|
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 elemenata kao što su davatelji elektroničkih identiteta, davatelji usluga te krajnji korisnici koji koriste dostupne usluge temeljem svojeg 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) 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 servisa je eduGAIN, a cilj mu je omogućiti funkcionalnosti jedinstvene autentikacije na europskoj i globalnoj razini za članove akademske zajednice.
| Info |
|---|
AAI@EduHr je punopravna članica eduGAIN-a od lipnja 2011. godine. |
Tipovi arhitekture federacije
Gledano kroz arhitekturu, federacije identiteta se obično dijele na mesh i hub-and-spoke tipove.
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 autentikacijskom servisu na 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 šalje, tj. 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. S 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 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 autentikacijskom servisu svih ustanova (davateljima 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. U ovom tipu arhitekture ustanove nemaju servis koji obrađuje autentikacijske zahtjeve, što implementaciju čini jednostavnijom. Korisnici unose svoje vjerodajnice na centralnom autentikacijskom 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 autentikacijskom servisu, čitava federacija prestaje s radom. Prednost ovog tipa arhitekture je da centralni autentikacijski servis predstavlja jedno mjesto uspostave povjerenja, te je implementacija novih autentikacijskih protokola jednostavnija (mora se implementirati samo na jednom mjestu, na centralnom autentikacijskom servisu).
| Info |
|---|
Arhitektura federacije AAI@EduHr je hub-and-spoke s centralnim autentikacijskim servisom, a komunikacija s bazom elektroničkih identiteta na ustanovi obavlja se HTTPS / SOAP protokolom. |
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 krajnjeg 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.
Usuglašavanje identifikatora za identitet
Bitna zadaća federacijskih protokola je omogućavanje da se različiti entiteti u federaciji usuglase oko toga koji atribut u elektroničkom identitetu će se koristiti kao identifikator, te u kojem formatu. Federacijski protokoli tipično omogućuju dva načina definiranja identifikatora:
- isti identifikator za različite usluge (različite usluge mogu povezati iste korisnike) - na primjer, OIB ili slično.
- različit identifikator za različite usluge (različite usluge ne mogu povezati iste korisnike) - formira se za svaku uslugu zasebno. Na primjer, to može biti hash vrijednost konkateniranih vrijednosti nekog identifikatora iz identiteta i identifikatora same usluge.
Usuglašavanje se obavlja razmjenom metapodataka između davatelja identiteta i davatelja usluga, pri čemu se, između ostalog, konfigurira koji atribut i u kojem formatu će se koristiti kao identifikator. Tako isti davatelj identiteta može za različite usluge vraćati različite ili iste identifikatore za istu osobu, ovisno o konfiguraciji.
Uz predodređeni identifikator konfiguriran u metapodacima, federacijski protokoli tipično omogućuju i da usluga bira koji identifikator i u kojem obliku želi (dinamičko definiranje identifikatora) prilikom samog autentikacijskog postupka.
Povjerenje i kriptografija
Federacijski protokoli tipično koriste funkcionalnosti iz kriptografije javnog ključa (engl. public key cryptography) za potpisivanje autentikacijskih poruka i dokumenata (dokumenti mogu biti npr. metapodaci različitih entiteta u federaciji). Svrha korištenja kriptografije može biti zaštita podataka šifriranjem (kriptiranje, engl. encryption) ili verifikacija podataka pomoću digitalnog potpisa. Javni ključevi entiteta će tipično biti dostupni u metapodacima samih entiteta. Na primjer, davatelj identiteta će objaviti svoj javni ključ u svojim metapodacima, a davatelj usluge u svojim.
Kada su javni ključevi razmijenjeni, davatelj usluge može koristiti javni ključ od davatelja identiteta za šifriranje autentikacijskog zahtjeva kojeg šalje prema davatelju identiteta, a davatelj identiteta će onda koristiti svoj privatni ključ za dešifriranje autentikacijskog zahtjeva. Nakon toga, davatelj identiteta može autentikacijski odgovor šifrirati javnim ključem od davatelja usluge te ga poslati samoj usluzi. Davatelj usluge će onda koristiti svoj privatni ključ za dešifriranje autentikacijskog odgovora.
Uz šifriranje, autentikacijske poruke mogu biti i digitalno potpisane. Na primjer, davatelj usluge može digitalno potpisati autentikacijski zahtjev svojim privatnim ključem, a davatelj identiteta takav potpis može onda provjeriti pomoću javnog ključa od davatelja usluge. Nakon toga, davatelj identiteta može potpisati autentikacijski odgovor svojim privatnim ključem, a davatelj usluge takav potpis onda može provjeriti pomoću javnog ključa od davatelja identiteta.
Uz potpisivanje autentikacijskih poruka, često se obavlja i potpisivanje metapodataka samih entiteta, čime se omogućuje provjera ispravnosti i izvornosti samih metapodataka. Na primjer, davatelj identiteta može potpisati svoje metapodatke svojim privatnim ključem, a davatelj usluge onda može provjeriti takav potpis pomoću javnog ključa davatelja identiteta.
Autentikacija naspram autorizacije
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 dodatnog ili jačeg autentikacijskog mehanizma). 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.
Jačina autentikacije
Postoje različiti načini autenticiranja korisnika, a svaki od njih govori o tome koliko je sigurno da je osoba koja je obavila autentikaciju stvarni vlasnik elektroničkog identiteta kojim se osoba predstavila prilikom autentikacije.
Trenutno najrasprostranjeniji način autenticiranja korisnika je pomoću vjerodajnica u obliku korisničkog imena i zaporke. Ovaj način se smatra slabijim načinom autentikacije jer sa sobom nosi nižu razinu sigurnosti u odnosu na ostale autentikacijske mehanizme. Razlozi za nisku razinu sigurnosti proizlaze iz poznatih boljki rada sa zaporkama. Na primjer, ako se koristi prekratka zaporka, relativno lako ju je pogoditi. Kada se koristi preduga zaporka, korisnici ju često znaju negdje zapisati, pa ju je moguće lakše ukrasti. Ako dođe do krađe zaporke, korisnici često toga nisu svjesni (teško je primijetiti da je zaporka ukradena).
Jači načini autentikacije tipično koriste tehnologije kao što su
- jednokratne zaporke (one-time password, OTP)
- asimetrična kriptografija (par privatnog i javnog kriptografskog ključa)
- biometrijske tehnologije
Pri korištenju jednokratne zaporke, OTP se, na neki način, generira prilikom same autentikacije. OTP je moguće iskoristiti samo jednom, pa ga je teže ukrasti i iskoristiti. Na primjer, prilikom autentikacije OTP se može korisniku poslati na e-mail, ili korisnik može generirati OTP na prethodno registriranom uređaju ili mobilnoj aplikaciji. Korisnik unosi OTP u formu za autentikaciju i tako potvrđuje svoj identitet.
Pri korištenju asimetrične kriptografije u postupku autentikacije, korisnik može imati privatni ključ spremljen na nekom uređaju (USB ključ, mobitel), pametnoj kartici ili slično. Prilikom autentikacije, korisnik može potpisati autentikacijski zahtjev svojim privatnim ključem, a autentikacijski servis može provjeriti taj potpis pomoću korisnikovog javnog ključa i tako potvrditi korisnikov identitet. Sam postupak potpisivanja se može odraditi tako da korisnik npr. unese PIN na uređaju, klikne određeni gumbić ili slično.
Korištenje biometrijskih tehnologija kao što je (prepoznavanje otiska prsta, skeniranje lica ili oka) znači i visoku pouzdanost autentikacije, ali ima jednu manu. Naime, iako se to relativno rijetko događa, potrebno je imati na umu da u slučaju oštećenja ili gubitka biometrijskog elementa korištenog pri autentikaciji, njega više nije moguće npr. ponovno izdati kao što je to moguće u drugim mehanizmima autentikacije. Dakle, u takvim slučajevima često se obavlja prijenos na drugi način autentikacije, ili eventualno registracija drugog biometrijskog elementa za autentikaciju.
Višestupanjska autentikacija
Drugi način povećavanja sigurnosti autentikacije je korištenje višestupanjske autentikacije (MFA, Multi-Factor Authentication) u kojoj je korisnik autenticiran nakon što se uspješno autenticira kombinacijom dvije ili više metoda autentikacije. Pri tome se može kombinirati autentikacija pomoću onoga što korisnik zna (npr. korisnička oznaka i zaporka) s autentikacijom putem onog što korisnik ima (npr. uređaj za generiranje OTP-a, pametna kartica) i/ili s autentikacijom putem korisnikovih biometrijskih podataka (npr. otisak prsta).
| Info |
|---|
Sustav AAI@EduHr omogućava dvostupanjsku autentikaciju tako da se kao prvi stupanj koristi metoda autentikacije korisničkom oznakom i zaporkom, a kao drugi stupanj neki od sustava koji generira jednokratne zaporke (tokene). |
Jedinstvena autentikacija (engl. Single Sign-On - SSO)
Jedna od funkcionalnosti koju definiraju federacijski protokoli je jedinstvena autentikacija (engl. Single Sigh-On - SSO). Jedinstvena autentikacija znači da se krajnji korisnik autenticira samo jednom (u nekom periodu), a nakon toga pristupa različitim uslugama na različitim domenama bez potrebe za ponovnom autentikacijom.
Da bi jedinstvena autentikacija funkcionirala između različitih usluga, usluge moraju delegirati autentikaciju istom autentikacijskom servisu. Na primjer, usluga A dostupna na https://usluga-a.primjer i usluga B dostupna na https://usluga-b.primjer delegiraju autentikaciju davatelju identiteta C dostupnom na https://davatelj-identiteta.primjer. Ako korisnik pokuša pristupiti usluzi A, ona će ga preusmjeriti na autentikaciju na davatelja identiteta C na autentikaciju. Nakon uspješne autentikacije na davatelju identiteta, korisnik sada može pristupati i drugim uslugama, dakle i usluzi B, bez potrebe za ponovnom autentikacijom.
| Info |
|---|
Jedinstvena autentikacija u sustavu AAI@EduHr može se obaviti preko protokola |
SSO sjednica
Generalno govoreći, nakon što se osoba autenticira u nekom sustavu, za nju se tipično otvara tzv. 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. Tako sustav ne mora za svaku radnju tražiti ponovnu autentikaciju i podatke iz identiteta. Uz to, sustav tipično ima postavljeno 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.
U slučaju obavljanja jedinstvene autentikacije korisnika, tipično će postojati bar dva mjesta na kojima će se otvoriti korisnička sjednica. Jedna će biti otvorena na samoj usluzi (ili više usluga ako korisnik pristupi više usluga), a druga na strani davatelja identiteta tj. na strani autentikacijskog servisa. Sjednica na strani autentikacijskog servisa se naziva SSO sjednica i ona je razlog zašto korisnik ne mora ponovno unositi vjerodajnice nakon što se prvi put autenticira na autentikacijskom servisu (u nekom periodu). Uz vođenje same SSO sjednice, autentikacijski servis će tipično voditi i evidenciju o tome na kojim sve uslugama korisnik ima otvorenu sjednicu.
Funkcionalnost SSO sjednica realizirana je kroz standardno korištenje kolačića (engl. cookies) u web preglednicima.
| Info |
|---|
U sustavu AAI@EduHr trajanje sjednice je 8 sati. To znači da se osoba, nakon što se prvi put prijavi u sustav AAI@EduHr, ne mora ponovno prijavljivati sljedećih 8 sati. |
Uloga web preglednika u SSO
U federacijskim protokolima tipično se koristi web preglednik za obavljanje jedinstvene autentikacije, a razloga za to je više.
Prva funkcionalnost web preglednika koja se koristi prilikom jedinstvene autentikacije je HTTP preusmjeravanje. Pomoću HTTP preusmjeravanja u web pregledniku, davatelj usluge može krajnjeg korisnika preusmjeriti na autentikacijski servis davatelja identiteta, a davatelj identiteta onda može, nakon autentikacije, preusmjeriti korisnika natrag na davatelja usluge.
Drugo, uloga web preglednika je i realizacija funkcionalnosti SSO sjednice pomoću kolačića.
Treće, web preglednik ima i ulogu neovisne aplikacije u koju krajnji korisnik unosi svoje vjerodajnice (npr. korisničko ime i zaporku, ili neki drugi oblik vjerodajnica), te služi za prijenos korisničkih atributa između davatelja identiteta i davatelja usluge. Naime, čak i ako su usluge realizirane kao nativne aplikacije (npr. mobilne aplikacije), uvijek će se koristiti web preglednik za unos vjerodajnica i slanje autentikacijskih poruka i odgovora. Time se osigurava da korisnik ne unosi vjerodajnice u aplikaciju nad kojom kontrolu ima samo davatelj usluge, tj. osigurava se da korisnik unosi vjerodajnice samo na strani davatelja identiteta.
Izazovi s kolačićima u SSO
Jedna od svrha korištenja kolačića u HTTP komunikaciji između web preglednika i nekog servera je očuvanje stanja (engl. state) između različitih HTTP zahtjeva (HTTP protokol je inače stateless). Tako se mogu voditi korisničke sjednice na serveru, odnosno provjeriti je li korisnik autenticiran ili slično. Druga svrha korištenja kolačića spremanje korisničkih podataka ili postavki. Na primjer, kolačići se mogu koristiti za spremanje naznake prihvaćanja uvjeta korištenja usluge, ili spremanje postavka jezika sučelja usluge, ili slično.
Treći, sve više problematičan način korištenja kolačića je praćenje korisnika na internetu u svrhu, npr. prikazivanja prilagođenih reklama. Naime, praćenjem navika korisnika prilikom surfanja na internetu, te praćenjem sadržaja kojeg korisnik konzumira, korisniku je moguće prikazati ciljane reklame, tj. one koje bi ga mogle najviše interesirati.
Kako bi se zaštitila privatnost korisnika, donesene su regulative (GDPR, ili ranije ePrivacy Directive (EPD)) koje definiraju kada i u koju svrhu se kolačići mogu koristiti, te nužnost informiranja korisnika o korištenju kolačića. Rezultat je da korisnik treba dati suglasnost za korištenje kolačića, a iznimno usluga može koristiti kolačiće i kada ima legitimni interes.
Uz regulative koje definiraju način korištenja kolačića, proizvođači web preglednika su počeli implementirati tehničke restrikcije u svrhu bolje početne zaštite privatnosti korisnika na internetu. Jedna od takvih zaštita je korištenje atributa SameSite koji određuje u kojem kontekstu će se kolačići moći razmjenjivati između servera i web pregledanika u komunikaciji između različitih domena.
Pošto se vođenje SSO sjednice oslanja na funkcionalnost korištenja kolačića između različitih domena (davatelj identiteta i davatelj usluge su na različitim domenama), atribut kolačića SameSite ima direktan utjecaj na obavljanje postupka jedinstvene autentikacije. Stoga, prilikom konfiguriranja davatelja identiteta ali i same usluge, potrebno je voditi računa da se na ispravan način podesi atribut kolačića SameSite.
Dijagram obavljanja SSO autentikacije na primjeru sustava AAI@EduHr (video)
| Multimedia | ||||||
|---|---|---|---|---|---|---|
|
Kratki opis postupka:
- oblak davatelja usluga se odnosi na više različitih usluga. Korisnik prvo pristupa jednoj usluzi (na kojoj nije lokalno autenticiran), a koja preusmjerava na autentikaciju na AAI@EduHr autentikacijski servis. Za preusmjeravanje se koristi web preglednik, neovisno radi li se o usluzi realiziranoj kao web aplikacija ili kao nativna aplikacijama (na nativnim aplikacijama će se podignuti sistemski web preglednik). Efektivno se šalje određeni HTTP zahtjev na određeni URL na središnjim autentikacijskim servisima po SSO protokolu
- središnji autentikacijski servis provjerava je li korisnik već autenticiran. U ovom slučaju nije, stoga se obavlja preusmjeravanje na autentikaciju na određeni URL na središnjem servisu. Pritom se kreira i korisnička sjednica te se postavlja kolačić koji sadrži identifikator SSO sjednice
- na autentikacijskom URL-u na središnjem servisu korisnik unosi vjerodajnice. Nakon toga, u slučaju AAI@EduHr federacije, u pozadini se koristi AOSI Web Service (WS) na korisnikovoj matičnoj ustanovi za autentikaciju i dohvat atributa. Po uspješnoj autentikaciji, usluzi se vraćaju korisnički atributi.
- kada korisnik pristupi drugoj usluzi na kojoj nije lokalno autenticiran, također se obavlja preusmjeravanje na središnji autentikacijski servis. No, ovaj put web preglednik će ujedno poslati i kolačić koji sadrži ID SSO sjednice. Središnji servisi će provjeriti valjanost sjednice, dohvatiti korisničke podatke iz cache-a, te odmah vratiti autentikacijski odgovor usluzi (korisnik se nije trebao ponovno autenticirati).
Jedinstvena odjava (engl. Single Logout - SLO)
Uz jedinstvenu autentikaciju, federacijski protokoli tipično omogućuju i jedinstvenu odjavu (SLO), dakle odjavu korisnika sa autentikacijskog servisa i sa usluga. Pošto sjednice postoje na više mjesta (na autentikacijskom servisu i uslugama), prvo treba odlučiti što se uopće treba dogoditi u kojem scenariju. Na primjer, treba li se dogoditi jedinstvena odjava ako istekne sjednica na nekoj usluzi ili samo ako korisnik sam inicira odjavu npr. klikom na gumb za odjavu? Treba li se ukidanjem sjednice na usluzi ukinuti i SSO sjednica na autentikacijskom servisu?
Ako se treba dogoditi jedinstvena odjava, usluga tipično šalje zahtjev za odjavom prema davatelju identiteta tj. autentikacijskom servisu, a autentikacijski servis onda poduzima daljnje korake kako bi korisnika odjavio sa svih usluga na kojima je trenutno autenticiran. Općenito govoreći, SLO se može obaviti na dva načina:
- odjava u prednjem kanalu (engl. front-channel)
- odjava u pozadinskom kanalu (engl. back-channel)
Odjava u prednjem kanalu se obavlja pomoću web preglednika koji se koristi za slanje HTTP zahtjeva prema određenim URI-ima na uslugama koji služe za odjavu korisnika. Davatelj identiteta će tipično na neki način automatizirati taj postupak, na primjer pomoću skripte u web pregledniku ili učitavanjem URI-a za odjavu pomoću iFrame-a, ili slično. Odjava u pozadinskom kanalu se obavlja tako da autentikacijski servis direktno šalje zahtjeve za odjavom prema uslugama na kojoj je korisnik bio autenticiran (ne koristi se web preglednik).
Postoji mnogo izazova u obavljanju jedinstvene odjave i zna se dogoditi da je implementacija odjave kompliciranija od implementacije autentikacije. Razlog za to je postojanje više sjednica (SSO sjednica i sjednice na samim uslugama) koje je potrebno ukinuti, a ima dosta mjesta gdje stvari mogu poći po krivu. Na primjer, prilikom obavljanja odjave u prednjem kanalu, ako se dogodi greška na strani usluge ili je usluga trenutno nedostupna, daljnji postupak odjave može stato (web preglednik može ostati "zaglavljen" na usluzi na kojoj se dogodila greška). Također, postoje izazovi u ispravnom konfiguriranju kolačića, jer se zahtjevi za odjavu (kao i za autentikaciju) šalju između različitih domena (davatelj identiteta i davatelj usluge su na različitim domenama), a sve ovisno o tome na koji način se šalju sami zahtjevi (npr. koriste li se HTTP POST zahtjevi ili HTTP GET zahtjevi pomoću redirekcije ili slično). S druge strane, prilikom odjave u pozadinskom kanalu postoje izazovi s uklanjanjem kolačića za vođenje SSO sjednice iz web preglednika
...
.