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.
