Ivan Pavić
Autor:
Ivan Pavić

C#.Net developer, Scrum master

Claims-Based Authentication - Single Sign-On Anywhere

Autentikacija i autorizacija korisnika su neizostavni dio svake imalo kompleksnije aplikacije, ali istovremeno i dio kojemu se prilikom projektiranja pridodaje najmanje pažnje. Tipično rješenje obično vodi prema starom ASP.NET Membership provideru ili nekoj njegovoj adaptaciji koji sve podatke o identitetu i profilu čuvaju u lokalnoj bazi podataka. Ako baš moramo koristiti AD račune, onda se tu još napiše pokoji LDAP Query i to je to.  Ali kako to izgleda kada unutar istog sustava već postoje aplikacije koje također koriste svoje lokalne identitete?

Broj korisničkih imena i zaporki koje korisnik mora pamtiti je jednak broju aplikacija koje koristi. Naravno, prelaskom iz jedne u drugu aplikaciju, korisnik se mora ponovno autenticirati. Informaciju o promjeni radnog mjesta je potrebno propagirati kroz sve aplikacije kojima korisnik pristupa. Administrativni poslovi vezani uz održavanje podataka o korisnicima vrlo brzo postaju teret i nema mehanizma koji bi osigurao konzistentnost podataka na razini cijelog sustava. 

Kako bi se izbjegli problemi ove prirode moguće je, gdje situacija to dopušta, koristiti Windows autentikaciju i Kerberos protokol kojima se informacije o korisnicima sele u zajednički Identity Store (Active Directory). Windows autentikacija tada omogućava i Single Sign-On za sve aplikacije unutar sustava. Implementacija u kodu je još jednostavnija od ASP.NET Membershipa. Dovoljna je samo jedna linija u Config datoteci i .NET sav prljavi posao obavlja za nas. 

 Ali što ako aplikacijama moraju pristupati i djelatnici koji pripadaju nekoj drugoj domeni ili pripadaju organizaciji koja uopće nema Windows domenu? U tom slučaju je potrebno "zatrovati" bazu korisnika sa tuđim podacima i odgovarati za njihovu točnost. Naravno, da bi stvar uopće radila preko AD-a, tim korisnicima je potrebno putem VPN-a osigurati i pristup tom istom AD-u kako bi se uopće mogli autenticirati.  Administracija internih korisnika više nije toliki problem, ali što je sa korisnicima aplikacija koji ne pripadaju matičnoj domeni? Možete li se osloniti da će vam partnerska tvrtka javiti da je jedan njihov zaposlenik dobio otkaz i da mu trebate zabraniti pristup svojoj aplikaciji?

 Što ako IT odjel unutar matične domene želi promijeniti sigurnosnu politiku  i umjesto korisničkog imena i zaporke koristiti pametne kartice? U tom slučaju imate trošak prilagođavanja svake aplikaciju zasebno.Što ako odluče da žele Single Sign-On za sve korisnike bez obzira na domenu i razvojnu platformu koju koriste? 

Ovo su sve dobro poznata ograničenja Kerberos protokola i lokalnih Identity providera, ali koja je alternativaClaims-Based autentikacija pokušava riješiti problematiku ove prirode već nekoliko godina. Claimovi nisu nikakva novost, ali su tek odnedavno postali integralni dio Microsoft .NET Frameworka. Implementacija od strane Microsofta je počela sa Frameworkom 3.5 gdje je predstavljena prva verzija Claims-Based implementacije pod imenom Windows Identity Foundation (WIF). Sa Frameworkom 4.5 je doživjela upgrade pod imenom WIF 4.5 dok je sa Frameworkom 4.5.1 postala integralnim dijelom Frameworka. Jedine očite promjena nastale integracijom su jednostavnije sekcije u konfiguracijskoj datoteci aplikacije i drugi namespace samog assembly-ja. Microsoft.Identity je postao System.Identity.

Magija u pozadini

Claims-Based autentikacija koristi SAML tokene ugrađene u standardni HTTP POST, SOAP poruke, Simple Web Token(SWT) unutar HTTP header-a u slučaju REST servsa i kriptirane Cookie-je za čuvanje session-a. Komunikacija između servisa se obavlja po standardima koji pripadaju WS* EkstenzijamaAko prevedemo gore navedene akronime, Claims-Based autentikacija radi sa sa svim modernim browserima, svim vrstama web servisa, pametnim klijentima i na svim platformama.

Kako to ustvari radi?

Ovisno o vrsti aplikacije koju razvijate Claimovi koriste malo drugačiju tehniku ali su osnovni koraci u principu isti jer je i cilj uvijek isti: Prebaciti Claimove od Identity Providera do aplikacije na siguran način. U tom smislu implementacija se dijeli u dvije osnovne skupine.

Browser-Based aplikacije 

Mehanizam autentikacije se odnosi na aplikacije kojima se pristupa pomoću browsera. Osnovni set koraka potrebnih za autentikaciju putem browsera prikazan je na sljedećem dijagramu.

  1. Neautenticirani klijent pokušava pristupiti aplikaciji.
  2.  WIF detektira neautenticirani zahtjev i preusmjerava zahtjev Identity Provideru.
  3. Identity Provider provjerava autentičnost aplikacije koja je poslala zahtjev i klijentu šalje formu za unos pristupnih podataka.
  4. Identity provider autenticira korisnika pozivom na Identity Store za koje je konfiguriran (AD, Google, Facebook). Ako je potrebno, radi mapiranje Claimova i vraća ih aplikaciji.
  5. Aplikacija (WIF) provjerava autentičnost Security tokena provjeravajući digitalni potpis i dozvoljava klijentu pristup stranicama. WIF kreira Session Token kako se cijeli proces nebi morao ponovno obavljati.

     Active-Client aplikacije

    U slučaju kada pokušavate pristupiti Web servisu ne postoji mogućnost preusmjeravanja putem web browsera. Umjesto toga klijentska aplikacija mora sadržavati logiku potrebnu za prijenos Claimova od Identity Providera do samog Web servisa koji ih očekuje. Dijagram prikazuje osnovni set koraka potrebnih za autentikaciju na Web servis koji koristi Claims-Based autentikaciju.

    1. Klijent u WSDL-u servisa dobiva informaciju o adresi Identity Providera kojega web servis koristi za autentikaciju pa se može bez preusmjeravanja autenticirati direktnim zahtjevom prema Identity Provideru
    2. Identity Provider klijentskoj aplikaciji vraća potpisani SAML token za daljnje korištenje.
    3. Klijentska aplikacija poziva metodu web servisa sa SAML tokenom u Security Headeru SOAP poruke. WIF na strani web servisa validira Security Token i dopušta klijentu pristup resursima na servisu.

    Što su uopće Claimovi?

    Claimovi su jednostavno skupina tvrdnji koje jedan subjekt izdaje za sebe ili za nekoga drugoga koje dolaze upakirane u token povjerenja (Security Token). Taj subjekt u svijetu Claimova najčešće zove Identity Provider ili Issuer i predstavlja autoritet kojemu vjerujemo. Idenetity Provider može u nečije ime izdavati Claimove. Na primjeru iz stvarnog života policijska uprava izdaje osobnu iskaznicu na kojoj stoji nekoliko Claimova: Ime, Prezime, Datum rođenja... . U IT svijetu, ta osobna iskaznica bi predstavljala Security Token, a podaci na njoj Claimove.

    Jednostavno, jedino što trebamo napraviti je provjeriti autentičnost osobne iskaznice i pročitati podatke koji su nam potrebni. Naravno, informatičari su sofisticirani pa autentičnost iskaznice ne provjeravaju golim okom već digitalnim potpisom.

    Aplikacija više ne implementira autentikacijsku logiku, ne brine se dali je klijent donio domovnicu, rodni list, slike u ispravnoj veličini, uplatio nekoliko uplatnica u državni proračun, platio biljege... To je već učinio netko prije, netko kome aplikacija vjeruje. U aplikacijama sa lokalnim identitetima bi taj isti klijent morao putovati od aplikacije do aplikacije noseći sve te papire koje već nebrojeno puta pokazivao, i to unutar istog sustava. Bilo koja osoba koja je imala posla sa velikom birokracijom zna koliko je to frustrirajuće. 

    Što ja zapravo dobivam?

    Claims-Based Autentikacija (CBA) omogućava razdvajanje aplikacija od detalja identiteta. Sa Claimovima vaša aplikacija više ne mora brinuti o autentikaciji korisnika, zaboravljenim zaporkama i sl. Jedino što vaša aplikacija treba je Security Token izdan od strane providera kojemu vjerujete. Aplikacija ne treba biti mijenjana, ponovno kompajlirana, možda čak niti rekonfigurirana ako netko odluči mijenjati sigurnosnu politiku tvrke. Claims-Based autentikacija je dizajnirana da prelazi granice Kerberosa (različite domene), firewall-ove, rad unutar web-farme servera i različite platforme. Omogućava Single Sign-On kroz različite domene i preko interneta.  Claims-Based autentikacija razdvaja autentikacijsku logiku i role od autorizacije. Omogućava više autentikacijskih metoda unutar iste aplikacije. Nudi mogućnost delegacije autentikacijskog procesa vanjskim servisima (Identity Federation) i dozvoljava siguran pristup internim resursima bez VPN-a.

    Što je dobar Claim?

    Kod odabira podataka koje jedan Security Token treba sadržavati nema jasnog odgovora. Količina podataka koje Identity Provider može vratiti je poprilično ograničena i ovisi prvenstveno o ograničenjima samog izvora podataka. Ako koristite Google account za autentifikaciju, Google ne može znati kojoj organizaciji pripadate (barem tako tvrde).

    Za kreiranje dobrih Claimova, bitno je razdvojiti podatke specifične za utvrđivanje samog identiteta od podataka specifičnih za aplikaciju. Kao smjernice za dizajniranje "dobrog" Claim možete koristiti slijedeći upitnik:

    1. Dali je podatak dio temeljnog identiteta korisnika?
    2. Dali je Identity Provider autoritet za taj podatak? Može li vam ga dati?
    3. Dali će se podatak koristiti u više aplikacija?
    4. Dali je bolje da Identity Provider administrira podatke ili je to bolje ostaviti na brigu samoj aplikaciji?

    Uloga Identity Providera

    Razumijevanje i odabir Identity Providera (IdP) kojem će vaša aplikacija vjerovati je najvažnija stvar u implementaciji Claims-based autentikacije. U Microsoft svijetu nude se dvije out-of-the-box opcije. Active Directory Federation Services (ADFS) i Windows Azure Access Control Service (ACS). Bez obzira koju opciju odaberete Identity Provideri imaju 3 osnovne zadaće.

    Autentikacija korisnika

    Primarna zadaća IdP-a je implementacija autentikacijske logike. Određuje način na koji će se korisnici autenticirati. Ako koristite ADFS na raspolaganju su Vam sve opcije koje nudi Windows domena. Također, Identity Provider može taj posao delegirati i nekom drugom Identity Provideru, tj. prihvatiti Security Token koje je izdao neki drugi Identity Provider, ako mu odluči vjerovati. Taj koncept se naziva Identity Federation i otvara zanimljive mogućnosti.

    Identity Federation

    Ako dvije tvrtke uspostave partnerski odnos i podignu IdP servise (svaka na svojoj strani), moguće je ostvariti scenarij gdje se korisnik iz tvrke A sa svojim domenskim podacima može ulogirati u aplikaciju koja se nalazi u domeni tvrtke B. Naravno, ako je već ranije unio svoje podatke (npr. Ulogirao se u računalo sa domenskim računom) aplikacija iz tvrtke B ga neće niti tražiti da ponovno unese podatke. Bitno je napomenuti da za ovaj scenarij nije potrebno uspostavljati spregu između dva AD-a. Korisnik se autenticira u AD-u tvrtke A koji za njega izdaje Security Token. AD tvrtke B vjeruje tom tokenu i dopušta pristup aplikaciji u unutr tvrtke B. 

    Mapiranje

    Treća zadaća Identity Providera je mogućnost mapiranja Claimova. Prilikom uspostavljanja povjerenja između 2 IdP-a, potrebno je Claimove transformirati u oblik koje aplikacija (Relying Party - RP) očekuje. Najbolji primjer su role i organizacijske jedinice unutar AD-a. Trvrtka A koristi organizacijske jedinice (npr. Sales) dok tvrtka B takve korisnike partnera tretira kao rolu OrderViewer. Zadatak IdP-a je organizacijsku jedinicu tvrke A premapirati u adekvatnu rolu tvrtke B. Na taj način aplikacija ne ovisi unutarnjoj organizacijskoj strukturi partnerske tvrtke.

    Active Directory Federation Services 2.0 (ADFS)

    ADFS je dostupan kao ekstenzija postojećeg AD-a kojega je moguće koristiti kao IdP za aplikacije koje se nalaze unutar jedne domene. ADFS implementira logiku za autentikaciju korisnika na više načina: Kerberos, Forms ili Cerifikati. ADFS je moguće konfigurirati da vjeruje i drugom Identity Provideru kao što je Windows Azure Access Control Service (ACS) ili nekom drugom ADFS servisu iz druge domene. Prednost korištenja ADFS-a kao Identity Provider-a omogućava i delegiranje brige oko autentikacije uspostavljanja federacije sa developera na sistem administratore. Dodavanje novog federacijskog partnera ne uzrokuje nikakve izmjene u kodu aplikacije. Dodatna prednost ADFS-a je mogućnost izgradnje vlastitog sustava za upis i administraciju korisnika ukoliko želite taj proces automatizirati. Drugim riječima, omogućavate kontrolirani pristup tvrtkama koje nemaju vlastiti IdP, ali koriste račune od drugih dobro poznatih Identity Providera (Google, Live ID, Facebook i sl.).

    Windows Azure Access Control Service (ACS)

    Iako ne postoji prepreka da ADFS prihvaća Claimove dobro poznatih Identity Provider-a ponekad je za korištenje socijalnih računa bolje koristiti ACS. ACS već ima predefinirani set IdP-ova i pravila za mapiranje Claimova koje bi u slučaju ADFS-a morali sami konfigurirati. Kroz administracijsko sučelje ACS-a je moguće dodavati nove IdP-ove i nova pravila mapiranja. Naravno, vaša aplikacija može ACS koristiti kao primarni IdP pa preko njega napraviti federaciju identiteta sa nekim drugim ADFS-om. Odluka o odabiru primarnog IdP-a (ADFS vs ACS) ovisi  o tome dali ste spremni prihvatiti dodatne za usluge i jednostavnost korištenja ACS-a ili prihvatiti odgovornost za ispravno tumačenje i mapiranje Claimova on-premise.

    Od kuda početi?

    Postoji nekoliko generalnih koraka za set-up Claims-Based rješenja koje goto svaki sustav zahtjeva. Razumijevanje ovih koraka će Vam pomoći kod prve implementacija Claims-Based arhitekture i olakšati snalaženje u prilikom detaljnijeg proučavanja teme.

    Korak 1: Dodajte podršku za Claimove u aplikacijsku logiku

    Aplikacija koja implementira Claimove mora biti svjesna postojanja Claimova, kako ispravno validirati Security Token i znati kako pročitati Claimove koji se u njemu nalaze. Windows Identity Foundation (WIF) pruža zajednički model za programski rad sa claimovima.Integracijom u .NET Framework je postignuta jednostavna nadogradnja postojećeg System.Identity namespace-a. Uz već postojeće i poznate metode i property-je (npr. IsInRole ili Identity.Name), Claimovi dolaze jednostavno kao novi property unutar System.Identity namespace-a (Identity.Claims). Property sadrži informacije o svim Claimovima koji su izdani, tko ih je izdao i njihov sadržaj.

    Korak 2: Odaberi ili izgradi Identity Provider

    Za većinu razvojnih timova korištenje ADFS-a ili ACS-a će biti najlakše i najsigurnije rješenje. Za one "specijalne" slučajeve gdje ADFS ili ACS ne zadovoljavaju kriterije, WIF Vam omogućava izgradnju vlastitog Identity Providera. Korištenje takvog sustava u produkciji nije preporučljivu ako niste Security eksperti, ali za razvojne potrebe može biti odlična opcija. Dok razvijate aplikacije, možete koristiti Stub Identity Providere koji vraćaju samo Claimove koji su Vam potrebni u razvojnoj fazi. Windows Identity Foundation SDK sadrži lokalni Identity Provider i primjere koje možete koristiti u toku razvoja aplikacije i za prototyping.

    Korak 3: Konfiguriraj aplikaciju da vjeruje Identity Provideru

    Sljedeći korak je uspostavljanje povjerenja između aplikacije i Identity Providera (Trust Relationship). Identity Provider ima mogućnost da digitalno potpiše svaki Claim koji izdaje kako bi aplikacija koja ih prihvaća mogla sa sigurnošću utvrditi da zlonamjerni korisnik nije presreo poruku i podmetnuo lažne Claimove. Potpisivanje je opcionalno i može se isključiti prema potrebi. Javni ključ certifikata, popis Claimova koje Identity Provider nudi, formate tokena i druge tehničke detalje vezane uz Identity Providera, aplikacija može dohvatiti ako od njega zatraži Federation Metadata. WIF automatizira ovaj posao kroz wizard za dohvat metapodataka Identity Providera pozivom na ispravan URL.

    Korak 4: Konfiguriraj Identity Provider da bude svjestan Vaše aplikacije

    Kako bi Identity Provider osigurao svoju funkciju, mora znati sljedeće informacije o Vašoj aplikaciji:

    1. URI aplikacije kako bi je mogao jedinstveno identificirati. URL aplikacije nemora odgovarati URI-ju.
    2. Koji od Claimova koje Identity Provider nudi su obavezni, a koji opcionalni.
    3. Dali je potrebna enkripcija Security Tokena.
    4. URL aplikacije kako bi mogao vratiti Security Token na ispravnu adresu.

     

     Gdje dalje ?

    Ukoliko Vam je tema interesantna, detaljnije informacije o Claims-Based autentikaciji možete pronaći u MSDN sekciji Microsoft patterns & practices   pod naslovom A Guide to Claims-Based Identity and Access Control (2nd Edition). Vodič detaljno objašnjava principe i mehanizme spomenute u ovm članku.

    Napomena

    Potrebno je napomenuti da je gotovo sva dokumentacija dostupna na intenetu vezana uz Windows Identity Foundation 4.5, .NET Framework 4.0 ili 4.5 a primjeri koda vezani za MVC 4. Kako je .NET Framework 4.5.1 relativno nov, Microsoft očito još nije ažurirao primjere koda i dokumentaciju vezanu uz WIF. Kako bi Vam skratio lutanja webom pokušat ću popisati ključne stvari na koje bi bilo dobro obratiti pozornost prilikom daljnjeg čitanja i istraživanja.

    Windows Identity Foundation 4.5 SDK

    SDK ove verzije je namijenjen za korištenje sa VS 2012 i .NET Framework 4.5. Konfiguracijske sekcije navedene u primjerima su promijenjene u Frameworku 4.5.1 (Ima ih manje i jednostavnije su). Za VS 2012 je postojala  ekstenzija Identity and Access Tool pomoću koje ste postojeći projekt mogli adaptirati za rad sa Claimovima. Ekstenzija za VS 2013 trenutno ne postoji stoga adaptaciju morate odraditi ručno. VS 2013 odabir autentikacijske i logike dozvoljava samo u trnutku kreiranja projekta. FedUtil.exe tool koji je sastavni dio WIF SDK 4.0 također koristi konfiguracijske sekcije za .NET Framework 4.5.

    Windows Azure Access Control Service (ACS)

    Prilikom kreiranja računa na Windows Azure Cloud platformi, sustav automatski kreira defaultnu instancu Windows Azure Active Directory-ja. Kreiranje ACS-a je opcija koja se nalazi unutar Azure AD-a, ali imam vlastitu Management konzolu i ničime ne utječe na rad Azure AD. Unutar jednog Azure AD-a je moguće kreirati neograničen broj ACS instanci. Također, bitno je znati da Windows Azure Active Directory nije isto što i Windows Server Active Directory. Dodatne informacije o ovoj temi možete pronaći na 9-om kanalu msdn-a.

    Visual Studio 2013 i Claims-Based aplikacije

    Prilikom kreiranja novog projekta npr. MVC 5 koristeći .NET Framework 4.5.1 potrebno je obratiti pažnju na opcije autentikacije kako bi aplikaciju spojili na ACS ili ADFS. U izborniku za odabir vrste ASP.NET aplikacije promijenite defaultni način autentikacije.

    Na izborniku za izmjenu autentikacije potrebno je odabrati Organizational Accounts.  U padajućem izborniku za odabir vrste host-a računa potrebno je odabrati On-Premises opciju. Znači, ako želite identity outsourcati u Cloud, nesmijete odabrati niti jednu od "Cloud - …" opcija, već odabrati On-Premises opciju. Logično, zar ne??!! U polje On-Premise Authority je potrebno upisati adresu metadata datoteke ACS servisa. App ID URI je jedinstveni identifikator Vaše aplikacije. Podatak nemora odgovarati URL-u na kojem se aplikacija nalazi. Primjer možete vidjeti na sljedećoj slici.

    Do točne adrese xml datoteke koja sadrži metapodatke samog ACS-a možete doći kroz ACS Management konzolu na putanji Application integration >> EndpointReference >> WS-Federation Metadata kako je prikazano na sljedećoj slici.

    Zahvaljujem na pozornosti.

    Popularne teme
    .NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone benchmark BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

    PRIJAVA NA NEWSLETTER

    Najnovije novosti iz ICT svijeta