Identity priča – kompleksno, a opet tako jednostavno

Identity priča – kompleksno, a opet tako jednostavno

Foto: Dražen Tomić

Otvoriti neku web stranicu koja me uz registraciju e-mail adrese traži definiranje korisničkog imena i lozinke, danas znači samo jedno - zatvorit ću browser prije nego se učita formular do kraja. Jednostavno, tom scenariju ne zanima me vaš servis, koliko god bio zanimljiv.

U 2013. godini, ako web aplikacija, bez obzira da li se radi o B2B ili B2C aplikaciji, da li se radi o javnoj ili privatnoj aplikaciji, zatraži od novog korisnika kreiranje još digitalnog identiteta, je doslovno neprihvatljivo. Ne želim imati još jedan password koji moram pamtiti ili upisivati u neki password manager. Ako vam programer počinje razvijati aplikaciju i planira čuvanje identiteta u svojoj bazi, vrijeme je da potražite nekog novog programera.

Koliko nam je digitalnih identiteta stvarno potrebno u životu? U idealnom svijetu naravno samo jedan, ali u realnosti, zbog osobnih želja i privatnosti, te zbog sigurnosnih rizika povezanih uz moguću krađu identiteta, realno trebamo 4 identiteta:

  • poslovni u tvrtki gdje radimo
  • privatni za osnovne web servise, od e-maila i foruma do različitih specijaliziranih servisa
  • privatni anonimni (iako je anonimnost u digitalnom svijetu zabluda, i naravno neću navoditi primjere gdje želite koristiti takav identitet)
  • privatni za državne servise (ovo isto neću komentirati u ovom tekstu)

Kod razmišljanja o korištenju digitalnih identiteta, moramo se malo dotaknuti tehnologije, tj. dva osnovna pojma: Kerberos, Claims Based Authentication.

Kerberos je osnovni autentikacijski servis kojem je mjesto unutar organizacija, ali samo za zaposlenike određene organizacije. Ako vam netko pokušava prodati Enterprise aplikaciju koja ne podržava Kerberos, tj. koristi svoj autentikacijski sustav, možete mu odmah pokazati vrata.

Čim pogledamo u svijet izvan jedne organizacije, Kerberos više nije primjenjiv. Čak ni kad imate partnerske tvrtke ili tvrtke u vlasništvu, zaboravite na Kerberos. Na scenu stupa „Claim Based Autentikacija“ i tzv. Security Token Services (STS). Zamislite scenarij kad želite dati pristup svojim aplikacijama ljudima koji rade u partnerskim tvrtkama, vašim korisnicima ili slučajnim namjernicima. Zamislite da ne morate brinuti o tome da li ste im kreirali korisničke račune u svojim sustavima, već jednostavno vjerujete digitalnom identitetu i autentikacijskom servisu u nekoj totalno trećoj organizaciji? Zvuči zastrašujuće otvoriti svoj svijet prema nekome koga ne poznamo i nemamo baš nikakvu kontrolu na njihovim sustavima i još im moramo vjerovati u potpunosti?

Bitno je napomenuti da se identity priče jako razlikuju u slučaju B2B i B2C aplikacija, o tome slijedeći put.

Evo jednostavan primjer klasičnog razmišljanja gdje za svoje partnere ili korisnike otvarate identitete u nekom svojem Extranet okruženju za pristup aplikaciji ili VPN-u i slično. Sve je ok, dok ta osoba radi još uvijek na istom radnom mjestu ili uopće još radi u toj organizaciji. Ali što ako ta osoba promijeni svoje radno mjesto ili još gore, promijeni posao i napusti organizaciju? Na koji način ćete vi toj osobi ograničiti pristup svojem sustavu ili promijeniti nivo prava pristupa? Da li će vas vaša partnerska tvrtka ili klijent uopće obavijestiti o promjeni radnog statusa svojeg zaposlenika? Primarno razmišljajte o B2B scenariju. Koliko je sigurnosnih rizika vezano u tom scenariju na stvari na koje ne možete ili jako malo možete utjecati, a to su poslovni procesi u tvrtki koja je samo vaš korisnik?

Koristeći STS servise i Claims Based Autentikaciju, navedeni scenarij se rješava toliko elegantno, da vi uopće ne morate niti znati za taj problem sa promjenom radnog mjesta ili statusom zaposlenika kod vašeg korisnika. Neka se o statusu i pravima korisnika, njegovim rolama u vašoj aplikaciji brine poslodavac koji zapošljava tu osobu, a ne vi.

Jedino što vas zanima je Token kojem možete vjerovati, tj. vaša aplikacija može vjerovati (to je samo pitanje tehnologije i nešto malo procesa, tako da se jednostavno može riješiti). I naravno zanimaju vas claimovi, tj. potvrde npr. e-mail adrese osobe, njegovu ulogu u organizaciji gdje radi (Role Based Security ili bar članstvo u security grupi) i svi oni claimovi sa atributima koji su bitni za vašu aplikaciju.

Prvi pristup u razvoju aplikacija koje podržavaju „Claims Based Authenticaton“ je započeo još prije 10-tak godina, koji je i danas nažalost još uvijek vidljiv u različitim primjenama. U prvoj fazi, razvoj aplikacija je išao u smjeru da aplikacija pozna i zna razgovarati sa raznim Identity providerima, tj. STS servisima koristeći različite vrte tokena (SAML, SWT, JWT, itd). To je noćna mora za programere, od poznavanja velikog broja tehnologija, do problema u održavanju takve aplikacije, jer se naravno STS servisi mijenjaju, razvijaju i jako brzo možete ostati na suhom, ako detaljno ne pratite sve dostupne tehnologije.

Rješenje je jednostavno, tj. koristiti „Identity Hub“, zapravo samo jedan jedini STS servis s kojim priča aplikacija, a taj STS servis povezivati sa drugim STS servisima (tj. providerima) koristeći različite tehnologije (primarno WS-Federation). Onda problem tehnologije prebacujete na sistemaše, a programeri se mogu fokusirati na razvoj aplikacija, a ne voditi brigu o tome kako se povezati na neku drugu tvrtku. Naravno programeri će imati posla oko razvoja automatizacije rada vašeg STS servisa, ali to je daleko jednostavnije od početnog pristupa.

Koji STS servis odabrati? U Microsoft svijetu je jako jednostavno, možete odabrati AD-FS 2.0 On Premise rješenje ili koristiti Azure verziju AD-FS servisa, tj. Azure ACS. Prve korake možete napraviti koristeći Azure Active Directory i povezivanje sa ACS-om i svojim aplikacijama. Microsoft je upravo objavio javnu dostupnost Azure Active Directory servisa, pa je idealan trenutak za ući u svijet „Claimova“ i jako čudnih naziva protokola i tokena.

Još iz kategorije

Speed, give me what I need

Speed, give me what I need

18.03.2019. komentiraj

Kad netko kaže da brzina znači život, to zvuči kao patetična izjava Toma Cruisea u „Danima groma“, ili takva neka holivudska smijurija. Međutim, u avionu to je vrlo doslovna i stvarna istina. Samo dok postoji dovoljna brzina opstrujavanja zraka oko površina zrakoplova, postoji i uzgon koji avion drži u zraku. Jedan od drilova koje instruktor upucava pilotu učeniku u glavu, kroz cijelo školovanje, je da pilot prvo leti, onda navigira, a tek onda razgovara s kontrolom leta. Ovo „prvo leti“ na prvom mjestu znači da održava brzinu aviona i odstojanje od prepreka.

Kako je Estonija postala napredna zemlja e-vladavine

Kako je Estonija postala napredna zemlja e-vladavine

06.03.2019. komentiraj

Estonija je dom najbolje očuvanog srednjovjekovnog grada u sjevernoj Europi, ali je u 21. stoljeću ipak najpoznatija po svojim naporima da se okrene prema budućnosti kroz impresivan sustav e-vladavine. Naime, spomenuti Talinn i ostali estonski gradovi daleko su moderniji i napredniji od mnogih u većim i bogatijim zemljama no što je Estonija.

Radio gaga … is all we hear

Radio gaga … is all we hear

04.03.2019. komentiraj

Charles Lindbergh, propali student tehničkog fakulteta, radio je kod nekog vlasnika nekog dvokrilca, fizičke poslove i poslove održavanja, a ne bi li ga ovaj učio letjeti. Bilo je tu i cirkuskih točaka stajanja na gornjim krilima aviona u letu, pri čemu Lindbergh nikako nije bio taj koji je zrakoplovom upravljao. Školovanje je išlo slabije nego šljaka, uglavnom zbog škrtosti gazde, tako da je mali od palube odradio tek nekoliko sati leta u nekoliko mjeseci. Kad je došao dan da bi mali trebao probati solo, gazda mu je samo stisnuo ruku i rekao „čestitam, pilot si“.