Naslov je kao oni klikbejt — nadam se, jer ste kliknuli da vidite o čemu se zapravo radi, obzirom da ovako napisan, ne znači baš ništa, ili gotovo ništa. U nastavku će se pokušati dati objašnjenje šta je to ustvari Federated Identity iz ugla programera.

IT industrija danas skoro pa dominira svijetom. Ako ne dominira, onda ima upletene prste u svakom mogućem poslu. Stoga je sasvim očekivano da se pojavljuju novi termini, kao i neki stari, ali s potpuno novim značenjem. Etimološko značenje mnogih termina koji se koriste u IT svijetu je veoma interesantno. Danas kada se kaže developer, nekako po automatizmu se podrazumijeva da je to softver developer, odnosno osoba koja izrađuje i/ili popravlja neki softver. Pa i sama riječ software je konstruisana mnogo prije riječi hardware, a koja se koristila još davne 1851. kojom se pobliže objašnjavala proizvodnja vunene ili pamučne tkanine, ili pak roba koja je veoma brzo/lahko kvarljiva. Stoga ćemo u ovom članku pokušati pobliže pojasniti neke veoma popularne termine tako da ih mogu s lahkoćom razumjeti softverski inžinjeri, ali i oni koji to nisu, a željeli bi znati nešto o ovome.

Svako od nas je čuo za SSO, OAuth, a neki od nas i za Federation Identity management, ali šta oni zapravo znače? Nekada se događa, srećom ne tako često, da kada čitamo neki članak na internetu vidimo da i sam autor ne raspoznaje baš najbolje pomenute termine. Rečenica tipa: “Federalni identitet za postizanje SSO-a uz pomoć SMAL-a” zvuči tako akademski i podrazumijeva da se mora imati veoma dobro znanje o ovim pojmovima, da bi ih se moglo ugurati u jednu ovakvu rečenicu. Stoga ćemo pokušati navoditi neke termine, davati njihovo pobliže objašnjenje, narodskim jezikom, te ih onda pokušati kombinovati i vidjeti koja je njihova uloga, odnosno svrha, te šta softver developer s njima može ili ne može da uradi.

Snadbjevači identiteta (Identity Providers — IdP) su sistemi s kojima se prave i nadgledaju informacije o identitetima. Ovi sistemi također snadbijevaju sistemimima za prijavu (npr, preko metoda za potvrdu korisnika) treće aplikacije (putem delegiranja) koje zahtijevaju potvrdu i prijavu korisnika.

Snadbjevači usluga (Service Providers — SP) su ustvari klijenti IdP-ova. Drugim riječima to su aplikacije kojima je delegirano zahtijevanje potvrde prijave i pristupa preko IdP-a.

Korisnički agenti (User Agents) su softverske aplikacije na strani krajnjeg korisnika. Kada se govori o veb aplikacijama, to je u principu veb pretraživač. Djelovanje krajnjeg korisnika na veb pretraživaču odražava se upitima prema snadbjevaču usluga. Drugi primjer su mobilne aplikacije ili korisničke aplikacije na operativnom sistemu PC-ja.

Korisnik (Users), su u principu osobe koje vrše neko djelovanje na sistem preko korisničkog agenta.

Prostim rječnikom kazano:

Kada krajnji korisnik (User), ili neka aplikacija koja glumi kranjeg korisnika, vrši neke radnje na krajnjoj aplikaciji, a koja se naziva Korisnički agent (User agent), ona šalje upite raznih vrsta pozadinskim servisima preko snadbjevača usluga. Ako korisnički agent, ili servis zahtijeva neku autorizaciju (potvrdu i/ili prijavu korisnika) tada taj servis, odnosno snadbjevač usluga tako nešto traži od snadbjevača identiteta.

Šta je Jedna prijava za sve (Single Sign On — SSO)?

SSO je proces provjere autentičnosti ili proces s kojim se omogućava korisnicima da se samo jednom prijave, a zatim dobiju pristup na više aplikacija ili usluga (zvani resursi). SSO nije protokol niti okvir (framework). On ne pravi nikakve pretpostavke o tome kako to treba postići.

Postoji nekoliko načina za implementaciju SSO rješenja. No, prije nego spomenemo bilo koje od rješenja valja napomenuti to da se uvijek trebaju, ili možda bolje rečeno, moraju poštovati standardi. Developeri veoma često vole da stvari rade na svoj način, a koji ovako ili onako odstupa od standarda i to kasnije gotovo uvijek stvara manje ili veće probleme. Dakle, rješenja mogu biti usmjerena na razne strane, ka tačno određenim korisnicima, ka tokovima ili procesima, ka korisničkim agentima i slično. Valja imati na umu nekoliko stvari dok se traži adekvatno rješenje, pa pokušajmo(te) odgovoriti na slijedećih nekoliko pitanja.

Ko su naši korisnici?

Da li su naši budući korisnici SSO rješenja zaposleni u firmi (Tzv. B2I — Business to Individual)? Tj., u firmi koristimo ili ćemo koristiti neka veb rješenja kao što je npr: Jira, GitHub, neka aplikacija za HR, finansije i slično.

Ili firma pruža ili planira pružati usluge kroz više aplikacija klijentima (Tzv. B2C — Business to Customer), te se želi klijentima olakšati pristup, tako što će im biti dovoljno da se prijave na jednu vašu veb aplikaciju i to će biti dovoljno za pristup cijeloj paleti aplikacija koje nudite?

Koje uređaje podržavamo?

Da li će naši korisnici koristiti samo veb aplikacije na radnim mašinama ili će ipak koristiti i mobilne te tzv. native aplikacije za razne operativne sisteme?

SSO pruža veliku paletu mogućnosti kako sistemskim administratorima tako i kranjim korisnicima, ali kao što je rečeno naprijed, važno je da se slijede standardi i prije same implementacije da se definišu određeni bazični, fundamentalni uslovi.

Upravitelj federativnim identitetima (Federated Identity Management — FIdM)

Prvo, šta je to federativni identitet?

Na bosanskom jeziku nisam uspio naći (prevedenu) definiciju. Ustvari, ne mogu da nađem gotovo ništa o ovom temi i to je jedan od razloga zašto sam se odlučio pisati na ovu temu, kao što pišem i na druge, slične ili ne, teme. Za potrebe ovog članka, tj. za one koji žele istraživati više, preveo sam nekoliko članaka na vikipediji, a koji su u direktnoj vezi s ovom temom. To naravno nije dovoljno, ali se nadam da je podsticaj drugim kolegama i kolegicama da se odvaže na prevod članaka na vikipediji.

No, idemo dalje. Prema (nezvaničnoj) definiciji koja se može naći na engleskom jeziku, u slobodnom prevodu na bosanski jezik, federativni identitet bi bio: “Federativni identitet se odnosi na identet osobe u jednom sistemu koji je povezan sa identitetom iste osobe u više drugih sistema”. Ako se nema barem osnovno znanje o SSO i FIdM ova definicija ne samo da je zbunjujuća nego ne znači gotovo ništa.

Federacija ustvari znači udruživanje. Ako bismo pokušali da nađemo primjer u svijetu izvan IT-a, onda je možda ponajbolje pogledati kako funkcioniše putovanje u zemljama EU. Zemlje EU su ostvarile neku federaciju, nekakvo udruživanje koje je negdje centralizovano i kao posljedica toga građani mogu da putuju širome EU (prelaze granice država) samo s ličnom kartom. Kao posljedica tog povjerljivog udruživanja gotovo da je nestalo međudržavnih granica, pa tako ljudi i robe mogu da putuju nesmetano. Dovoljno je otići u svoju opštinu ili neku drugu službu koja je ovlaštena (Service provider) od strance neke više instance za pristup ličnim podacima (Identity provider) i tada će operater (User) koji tamo radi na nekoj aplikaciji (User agent) da izda kartu (token) s odgovarajućim podacima sačuvanoj na njoj (rok valjanja, za šta je ta karta, lična, vozačka, zdravstvena, …)

Naravno, EU, nije nikakva federacija identiteta, nego federacija država, stoga, primjer iznad nije 100% tačan, ali pokušava približiti tematiku jednostavnim jezikom. Zato ćemo ući još dublje u navedeni primjer. Ako se vratimo sada na onu službu kod koje se ide po kartu, tu možemo naći jedan veoma praktičan primjer federacije identiteta (a koji se ne koristi za prijavu na aplikacije, nego samo daje još jednu, novu, širu sliku svega). Naime, operater ima pristup aplikaciji unutar koje će unijeti vaše lične podatke, dodati novu fotografiju i slično. Sve te vaše podatke operater u npr. domu zdravlja vidi automatski. Zašto? Zato što su reći ćemo baze uvezane. Upravo! Da li su baze uvezane ili je jedna baza u pozadini to sada nije bitno. Važno je da se shvati koncept federacije identiteta. Podaci koji se nalaze kod ljekara zasigurno se ne mogu vidjeti ni na koji način u opštini. Vaši podaci koji se nalaze u banci ne mogu se vidjeti kod ljekara i slično. Vide se samo podaci koji su označeni za federaciju, za dijeljenje.

Ako se sada vratimo u IT svijet ponovo i ono što nas zanima u ovom članku, to bi bilo slijedeće: Federacija identiteta povezuje identitete jedne te iste osobe iz raznih aplikacija. Pa tako, aplikacija u opštini ima svoju vlastitu bazu podataka, svaki korisnik (građanin) ima vlastiti ID u toj bazi. Svaki građanin se nalazi u bazi podataka zdravstva. U toj bazi građanin ima neki drugi ID u nekoj potpuno drugačije strukturisanoj bazi podataka. Fedaracija identiteta povezuje te dvije baze na nekom trećem mjestu i tačno zna da ID korisnika u aplikaciji iz opštine i ID korisnika iz aplikacije u domu zdravlja predstavlja jednu te istu osobu. Sada će neko vrisnuti: Aaaaa, mapiranje korisnika! Da, onaj koji je pomislio na to, dobro je pomislio! Čestitamo!

Idemo dalje. Svaka aplikacija za koju je potrebna prijava jer se žele sačuvati podaci zbog ovog ili onog razloga ima svoj vlastiti mehanizam (poslovnu logiku) za prijavu, čuvanje sjednica (sessions), zatim načini kako se registrovati, izgubio šifru i slično. Ako udružimo nekoliko ovih aplikacija tako da dijele identitete (neke od podataka iz svake aplikacije — a zaključuje se da su to na prvom mjestu pristupni podaci) onda se njihovo udruživanje naziva Federacija identiteta. Sada će neko reći, ali zar to nije SSO ili dio SSO-a?

Da li je FIdM dio SSO-a?

Odgovor je i Da, i Ne. Mnogi SSO-i se mogu implementirati bez FIdM-a, ali ipak većina savremenih implementacija koristi neki oblik FIdM. U svakom slučaju, nedajte se zavarati, šta je SSO, a šta FIdM. Nadamo se da je FIdM dobro objašnjen u prethodnom poglavlju.

Tok autentifikacije u federaciji

Ovaj portal, medium.com je pridružen federaciji identiteta. Snadbjevači identiteta (Identity Providers) za medium.com su Google, Facebook i Twiter. To znači slijedeće:

1. Kada korisnik otvori medium.com na veb pregledniku (iskren da budem nisam probao preko mobilne app, pa ne znam kako tamo hoda, ali vjerovatno veoma slično), medium.com ima pozadinsku skritpu (brezbeli neka JS) koja šalje upit na svakog od nabrojana tri snadbjevača da li je korisnik kod njih prijavljen.
   a) Ako je korisnik prijavljen, tada će se u gornjem desnom uglu pojaviti mali kao prozorčić s pitanjem: Želite li nastaviti kao Vaše ime i prezime.
   b) Ako korisnik nije prijavljen trenutno preko tog pretraživača ni na jednom od gore nabrojanih snadbjevača identitetima, neće se pojaviti ništa.
2. Ako se korisnik želi prijaviti na medium.com (kako bi recimo pisao svoj novi članak), tada će se nakon klika na izbor za prijavu pojaviti novi dialog gdje korisnik treba da izabere neki od ponuđenih načina. Preko Google, Facebook, Twiter ili pak da unese direktne pristupne podatke na medium.com.

Ovo do sada što smo vidjeli sve spada pod SSO. Za one koji imaju iskustva s SSO, ništa novo. Jednostavno prijava uz pomoć nekog snadbjevača identitetima i to je to. Za one koji ne znaju, caka je slijedeća:

1. Ako se korisnik prijavi na medium.com sa nekim od snadbjevača identetitetima, tada u lokalnoj bazi podataka na medium.com se ne čuva šifra (password). Nego se u bazu samo doda novi rekord preko kog će se znati da je to “vanjski” korisnik.
2. Međutim, ako se korisnik prijavi direktno na medium.com, tada će svakako i šifra biti zapisana u lokalnoj bazi mediuma.

Šta ovdje radi federacija i koji je njen tok?

Bez bespotrebnog teoretisanja, idemo pravo na konkretan primjer. I to ovaj gore iznad spomenuti.

1. Ako je recimo korisnik prijavljen na medium.com preko Google kao snadbjevača identitetima i slijedeći put dođe na medium, ali je zaboravio da li se prijavljivao preko Google, Facebook ili Twitter i klikne na Facebook.
   a) Ako za prijavu na Facebook, koristi Gmail (tj. Google kao snadbjevač identitetima), tada će Upravitelj federativnim identitetima znati da se radi o istom korisniku.
   b) Sutra ponovo ako korisnik dođe i ne sjeća se da li je prethodno koristio Google ili Facebook i pokuša s Twitter (pod uslovom da za prijavu na Twitter koristi Gmail), Upravitelj federativnim identitetima će opet znati da se radi o istom korisniku.
2. Korisnik će biti uspješno prijavljen, vidjeće sve svoje članke. Avatar ako je prethodno dodan i slično. Jedino šta će biti promijenjeno u pozadini, jeste da to da će sada svi identiteti (mi to obično kažemo profili) sa svih snadbjevača identitetima (Google, Facebook i Twitter) biti zaista i povezani — mapirani unutar jedinstvene baze Upravitelja federativnim identitetima.

Mogli bismo reći da je Federacija identiteta ustvari nadogradnja na već veoma zastupljeni SSO.

Također, za developere, veoma važna stvar je kako ostvariti svu komunikaciju između svih ovih silnih servisa. Odgovor je, uslovno rečeno, veoma jednostavan. To se radi uz pomoć veoma popularnog JWT žetona (Čita se džot, da se ne bi čitalo Dž, double v, T). JWT je veoma simpatična stvarčica koju ovdje nećemo uopšte obrađivati. Možda nekom drugom prilikom, a za one koji ne znaju šta je to, neka posjete zvaničnu stranicu www.jwt.io

Delegiranje prava na prijavu

Naravno, ne može medium.com niti bilo koja druga aplikacija tek tako znati da li je korisnik prijavljen na Google, Facebook, Twitter ili pak neki vaš interni Upravitelj federativnim identitetima. Da bi se ostvarila ta sigurna veza, potrebno je da se od strane aplikacije (medium.com) delegira pravo nekom IdM da može izvršiti prijavu za nju. Ako postoji više nezavisnih IdM-ova, kao u ovom primjeru s medium.com, tada se između njih uspostavlja sigurna, povjerljiva veza koja povezuje sve te identitete. Ta sigurna veza s svojim vlastitim servisom naziva se Federated Identity Management (FIdM), odnosno Upravitelj federativnim identitetima.

Standardni protokoli za uspostavu veza

Kao što smo spomenuli iznad, za implementaciju valja pratiti standard i biti dosljedan. Popularni protokoli preko kojih se ostvaruje SSO, kao i federacija je u nastavku.

Centralni protokol provjere autentičnosti (CAS)

CAS — Central Authentical Service Protocol je protokol koji se koristi kod implementacije Upravitelja federativnim identitetima. Inače, ovaj protokol je pravo nepopularan i rijetko koji, posebno otvorenog koda, servisi ga podržavaju. Kao što je Keycloak, WSO2, AWS Cognito i slično.

Jezik za označavanje sigurnosne tvrdnje (SAML)

SAML — Security Assertion Markup Language — je XML bazirani standard za razmjenu podataka o autentifikaciji i autorizaciji između sistema. Svakako u okviru ove naše teme i između IdP-a i SP-a. Za razliku od CAS-a koji je zaista protokol, SAML samo kreira odgovarajući XML kojeg aplikacije/servisi koriste.

Gotovo sva rješenja, bila ona komercijalna ili otvorenog koda podržavaju SAML. SAML je također, jedino rješenje za one koji žele da implementiraju SSO i FIdM na Windows Server rješenjima — Azure npr.

OpenID Connect

Prije svega valja razlikovati OpenID, od OpenID Connect, ali ovdje nećemo davati objašnjene razlika između njih.

OpenID je lagani (lightweight) protokol za provjeru autentičnosti koji se koristi kod REST baziranih servisa i JWT je ovdje gotovo pa nezaobilazan. Za više informacija o OpenID Connect, informisati se o OAuth2, ali paziti da se zna napraviti razlika između njih.

Zaključak

Prije svega želim da se izvinim svim ljubiteljima slika što ih nisam ubacio. Mnoga objašnjenja bi vjerovatno bila lakša uz slike, ali to bi mi oduzelo dodatnih sahat dva, a možda i više da ih napravim. Kao što se da primijetiti, pokušavam sve pisati na bosanskom, pa nisam htio da uzimam neke slike na engleskom i samo ih zalijepim ovdje.

A sada o Federaciji, ali ne onoj FBiH, nego federaciji identiteta o kojoj smo pisali iznad. Zaključak se nameće sam. Federacija identiteta se može koristiti u B2C i/ili B2I svijetu. Veoma je praktična stvar, ali njena impementacija naravno može da bude veoma složena u zavisnosti od toga kakvu paletu aplikacija imamo i želimo da ponudimo krajnjim korisnicima. Nije isto ako se želi iskoristiti neki javni IdP, kao što su Google, Facebook i slično ili neki naš, vlastiti koji mi vlastito održavamo, čuvamo, unaprjeđujemo. Nije isto ako su naše aplikacije monolitne ili koriste mikro servise itd itd.

0

Hits: 0