Uvod
Svi se sjećamo ključara iz Matrix-a. Onog malog čičice koji nosi tovar ključeva da bi otključao određenu sobu. Svi mi imamo po nekoliko ključeva jer time želimo sebe da zaštitimo, kao što imamo i nekoliko passworda (da li zaista imamo), pin kodova i slično. Kada ih imamo više i u slučaju da izgubimo ili bude ukraden jedan, nije nam ugroženo sve.

U hotelima nekada smo koristili klasični ključ s kojim smo mogli otvoriti sobe koje smo uzeli, a spremačica je morala imati kopiju ključeve od svake sobe. Kasnije smo te ključeve zamijenili elektronskim karticama, da ne kažemo ključevima. Kartica koju ima spremačica može da otvori još više vrata. Kartica šefa smjene još više. U hotelu postoji i kartica gazda, kralj, gospodar, glavna ili kako to mi inače zovemo, master, koja može da otvori sva vrata i toj kartici imaju pristup samo određene osobe.

Ključ ključara iz Matrix-a otključavao je ne samo vrata, nego i Izvor Jednog. Samo mali broj ljudi razmišlja koliko je ključar važan, jer svi usmjere pažnju na ključ i šta se s njim može. Međutim, ako ključar ne napravi ključ koji je punovažan za vrata, džaba svi ključevi svijeta. Za određena vrata odgovara samo i jedino tačno određeni ključ! Ovo nas dovodi do zaključka da ključar mora znati svoj posao i iznad svega toga biti povjerljiv. Jednom kada dođemo do ključara i zatražimo da nam napravi ključ, mi moramo da damo neke informacije o nama, u suprotnom to je kriminalno djelo. Dobro, u Bosni nije. Može da kopira ključ ko hoće i gdje hoće, ali u uređenom svijetu to ne ide tako. Treba li reći da u svijetu računara to ne ide tako, ali nikako?! Ovo nas sada dovodi do novog zaključka koji kaže: korumpiran ključar — korumpiran cijeli sistem!

SSO
Sada kada smo dobili barem neku sliku o kompleksnosti teme ključeva, ključara te distribucije ključeva trećim licima koja će ih na kraju koristiti, možemo ući u svijet računara i vidjeti šta se to tamo događa.
SSO je skraćenica od Single Sign On. Kada smo kod ovog Single Sign On, postoji još i Single Sign Off i Single Sign Out te Single Log Out i Single Log Off. Kako se da primijetiti skraćenice su SSO ili SLO ali su značenja suprotna jedna drugima i veoma često dolazi do zbunjujućih situacija.
SSO — Single Sign On predstavlja ustvari jedinstvenu prijavu (autentikacija) za cjelokupan set aplikacija između kojih je uspostavljena povjerljiva veza. Ili još preciznije, dovoljna je jedna prijava na nekoj “posebnoj” aplikaciji, a koja se u SSO svijetu zove snadbjevač identitetima, odnosno Identity Provider, često kratko označavan samo kao IdP (Ubačeno je malo d da se ne bi miješalo sa IP adresom). Neki hoće reći kako je ovo dostavljač identiteta, ali to nije tačno! Za piceriju se kaže da snadbijeva grad, neku instituciju ili nešto picama, a onaj momčić na skuteru što razvozi pice po gradu je dostavljač. Doduše, ima i onih koji kažu da su to pružatelji identiteta.

Primjer
Ova neka “posebna” aplikacija može biti uslovno rečeno bilo koja aplikacija na kojoj je implementirano rješenje da ona može biti dostavljač identiteta (IdP). Ako govorimo na globalnom nivou, za krajnje, “obične” korisnike, onda su neki od najpoznatijih dostavljača identiteta Google, Facebook, Twitter, GitHub i Butbucket.
Šta to ponovo znači?
Pa to u osnovi znači da se kranji korisnik nekada registrovao kod ovih IdP-ova i da se ta registracija (korisničko ime/email i šifra) pretvorena u neki sigurni ključ može koristiti kao pristupni ključ nekoj drugoj aplikaciji. Svakako, neke aplikacije zahtijevaju i dodatne podatke, kao npr. ako se zahtijeva prijava uz pomoć Facebook IdP-a, onda se od krajnjeg korisnika može tražiti da dozvoli pristup fotografijama ili nekom drugom sadržaju.
Povjerljiva aplikacija u ovom odnosu se često naziva RO (Resource owner) — vlasnik resursa. Ako se povjerljiva veza ostvaruje putem SAML protokola, tada na strani povjerljive aplikacije mora biti i SP (Service Provider), koji je most između RO i IdP-a.
Jednom prijavljen korisnik na povjerljivu aplikaciju ne znači i da korisnik ima potpuni pristup svemu. Autorizacija se odvija (uglavnom) na aplikativnom nivou.
Obzirom da se danas skoro svaka aplikacija (osim bankovnih možda) oslanja na neki od globalnih IdP-ova može se govoriti o globalnoj zastupljenosti koja se podrazumijeva. Naravno, ono što se podrazumijeva krajnjem korisniku, ne znači i da je jednostavno implementirati developeru.
SLO — Single Log Out (sinonimi: Single Sign Off, Single Sign Out i Single Log Off)
Mnogi zaboravljaju da jednom kada se korisnik prijavi, treba imati mogućnost i da se odjavi. Svakako, ako je implementacija prijave kompleksna, posebno po pitanju sigurnosti, ništa manje ni odjava nije laganija. Čak šta više, kod odjave postoji nekoliko odjava. Odjava na nivou aplikacije, ili koristeći SLO odjava s IdP-a, tako da će svi povjerljivi klijenti ustvari biti odjavljeni.
E ovdje se sada javlja mnoštvo pitanja. Npr, ako se koristi za SSO SAML kojem je Microsoft Active Directory IdP i ako korisnik na nekoj od, recimo, intranet aplikacija klikne za odjavu, je li to znači da će biti automatski odjavljen i iz Windows OS-a na svojoj mašini?
Šta će se dogoditi ako korisnik klikne na SLO odjavu u svojoj web aplikaciji, a IdP trenutno nije dostupan? Šta će biti sa cookies u pretraživaču, a šta će biti sa sesijom na IdP-u?
Čini se da je SLO mnogo složeniji od SSO-a, zar ne?
Zašto se koriste termini Log in, Sign In, Sign Up, Log Out, Sign Out i slično? Pa postoji mnogo razloga, ali ako se osvrnemo na jezički prije svega vidjećemo da se s Log pojmom ustvari daje do znanja korisniku da će sa pristupi koje obavlja čuvati (logirati), dok se s Sign više daje neki znak, pa se tako imaju znakovi za registraciju s Sign Up, prijavu s Sign In, te odjavu s Sign Out.
Za radoznale
No, postavlja se pitanje koja je razlika imeđu Log in i Sign in. Oba termina služe za prijavu, tamo gdje se već prije registrovalo. U svakom slučaju iz perspektive aplikacije korisnik će uvijek biti Log In ili pak Log On. Da li će se na aplikaciji koristiti termini Sign ili Log, može biti još i to da tamo gdje je čuvanje podataka o prijavama veoma važno (kao što su recimo bankarske aplikacije), tada se korisniku decidno može reći da se prijavljuje sa Log In, dok gdje to nije obaveza (kao kod newsletter) može se koristiti termin Sign In.
Jednom kada se posjeti neka stranica, tada je to iz perspektive aplikacije Log On. Korisnik će biti negdje zapisan da je posjetilac. Međutim, kada se prijavi sa Log In, on tada dobija svoj lični prostor na toj stranici.
Federacija identiteta
Ne, nije Federacija BiH! Ovo je neka druga federacija, odnosno udruživanje, savez, alijansa. I to federacija identiteta koje pružaju razni snadbjevači identitetima (IdP).
Prije smo rekli da se korisnik registruje na nekom IdP i da se taj identitet kasnije koristi u povjerljivim aplikacijama. Sada, s federacijom uspostavlja se neka vrsta povjerljivosti između IdP-ova.
Za federaciju je potreban jedan novi servis koji će vršiti tu federaciju, odnosno biće jedan novi servis, između IdP-ova i povjerljive aplikacije. Da bi ovaj servis radio svoj posao on mora imati vlastitu bazu podataka u kojoj će čuvati osnovne pristupne podatke krajnjih korisnika (bez šifre!). Najčešće je to samo e-mail adresa, ali u zavisnosti od složenosti aplikacija može biti i više podataka, naravno.
Ako se korisnik na neku povjerljivu aplikaciju već jednom prijavio uz pomoć, npr. Google IdP-a. To je sada sačuvano na servisu za federaciju identitetima. Slijedeći put, ako korisnik pokuša da se prijavi na povjerljivu aplikaciju uz pomoć nekog drugog ponuđenog IdP-a (npr, Facebook, ali uslov je da je za prijavu na Facebook korišten isti Google račun/gmail), tada će servis “znati” da se tu radi o istom korisniku. Servis će poslati povjerljivi ključ ka povjerljivoj aplikaciji preko kog će povjerljiva aplijacija znati da se radi o istom korisniku.
Drugi primjer korištenja federacije identiteta jeste takav da jednom kada se korisnik prijavi kod nekog IdP-a i posjeti bilo koju povjerljivu aplikaciju, tada će se na strani povjerljive aplikacije obaviti automatski upit ka servisu federacije identiteta da vidi da li je korisnik već prijavljen. Ako jeste, tada se imaju dva scenarija.
Jedan se koristi u korporacijama (uglavnom za intranet stranice) gdje je dovoljno da se korisnik prijavi na operativni sistem i već je automatski prijavljen na svim ostalim stranicama bez da treba kliknuti na bilo koje dodatno dugme, potvrdu i slično (svakako, samo unaprijed definisanim povjerljivim aplikacijama kojima baš taj korisnik može pristupiti).
Drugi scenario se veoma često sreće u zadnje vrijeme na internetu. Korisnik pristupa nekoj web aplikaciji, aplikacija pita servis za federaciju identiteta da li je korisnik već prijavljen kod nekog IdP-a s kojim je ostvarena povjeljiva veza. Ako jeste, tada će krajnji korisnik dobiti diskretnu obavijest o tome da li želi da se prijavi na povjerljivu aplikaciju “sa samo jednim” klikom.

Trenutno najpopularniji servisi za Federaciju identiteta su AWS Cognito kao komercijalno rješenje u oblacima i Keycloak kao rješenje otvorenog koda. I o jednom i o drugom ćemo ako Bog da u nekom novom ili novim člancima.
0Hits: 11