1 Uvod

U današnje vrijeme kada je nemoguće zamisliti svijet bez Interneta, autentifikacija igra ključnu ulogu u poboljšanju sigurnosti Web aplikacija. Kako bi se poboljšala kvaliteta usluge, povjerenje i sigurnost korisnika prilikom korištenja Web aplikacija potrebno je odabrati odgovarajući sustav autentifikacije.

U svijetu Web autentifikacije postoji velik broj sustava koji koriste različite metode i protokole za autentifikaciju. Prilikom projektiranja sigurnog sustava svakako najvažniju ulogu ima odabir odgovarajuće vrste autentifikacije za određeno okruženje. U okviru ovog rada načinjen je pregled metoda i protokola za Web autentifikaciju te detaljniji opis sustava za Web autentifikaciju pod nazivom MS Windows CardSpace.

Kako bi koncept koji se koristi u Windows CardSpace-u bio jasniji potrebno je pojasniti neke osnovne pojmove. Za početak bitno je razumjeti što je to digitalni identitet. Način na koji korisnik prikazuje svoj digitalni identitet mijenja se tijekom njegova kretanja svijetom. Kada svoju putovnicu pokazuje na zračnoj luci prepoznat je kao građanin neke države. Kada korisnik svoju vozačku dozvolu pokaže policajcu na uvid nakon što je zaustavljen, on je legalan vozač koji stanuje u nekom mjestu. Kada taj isti korisnik koristi svoju kreditnu karticu za plaćanje nekog računa on je korisnik nekog bankovnog računa. Iz ovog je vidljivo da se u različitim situacijama koristi različiti digitalni identitet koji se ovisno o situaciji drugačije interpretira i pruža drugačije informacije.

Sve ove situacije imaju jasan način utvrđivanja korisnikovog identiteta. U svijetu Interneta identitet je trenutno mnogo složenija stvar. Kao i u stvarnom svijetu i u digitalnom svijetu svaki korisnik posjeduje nekoliko digitalnih identiteta. Svaki od njih različito se interpretira ovisno o situaciji u kojoj se koristi. Danas ne postoji konzistentan način upravljanja portfeljem digitalnih identiteta. Umjesto toga korisnik se muči u kompleksnim, zbunjujućim i nesigurnim okruženjima.

U okviru praktičnog rada, programski je ostvaren sustav za pružanje usluge dodjele digitalnog identiteta koji omogućava generiranje osobnih i upravljačkih kartica te omogućava sigurnu autentifikaciju. Opisan je način korištenja jednostavne Web stranica koja omogućava takav oblik autentifikacije te neki tehnički detalji na koje treba pripaziti prilikom implementacije ovakvog sustava. Implementacija sustava ostvarena je na operacijskom sustavu MS Windows korištenjem ASP.Net tehnologije zasnovane na .NET Framework-u 3.0.

2 Sustavi za Web autentifikaciju

Autentifikacija može biti ostvarena na mnogo načina. Prilikom projektiranja sigurnog sustava svakako najvažniju ulogu ima odabir odgovarajuće vrste autentifikacije za određeno okruženje.

2.1 Pregled autentifikacijskih metoda

U pregledu je navedeno nekoliko autentifikacijskih metoda i protokola s ciljem boljeg razumijevanja mogućnosti koje se nude prilikom projektiranja sigurnog sustava.

2.1.1 Lozinke

Lozinke predstavljaju najčešće korišteni i najrašireniji oblik autentifikacije. Korisnicima se dodjeljuje identifikator, upisana riječ, fraza ili kartica, zajedno s lozinkom. U mnogim sustavima na računalu domaćina, lozinke se ne spremaju kao čisti tekst nego su kriptirane. Autentifikacija lozinkama ne zahtjeva složenu i zalihosnu sklopovsku opremu jer je ovaj oblik autentifikacije vrlo jednostavan i ne zahtjeva mnogo procesorske snage. Autentifikacija lozinkom ima nekoliko ranjivosti, od kojih su slijedeće najočitije:

mogućnost laganog pogađanja lozinke,

zapisivanje lozinke i stavljanje iste na vidljivo mjesto,

otkrivanje lozinke prisluškivanjem ili društvenim inženjeringom.

Rizik od prisluškivanja moguće je smanjiti korištenjem sažetka prilikom autentifikacije. Povezujuća strana šalje informaciju koja je zapravo sažetak klijentske IP adrese, vremenske oznake i dodatne tajne informacije. Budući da je ovakav sažetak jedinstven za svaki URI kojem se pristupa, nije moguće pristupiti niti jednom drugom dokumentu niti ga je moguće koristiti sa drugih IP adresa bez otkrivanja. Samim time, lozinka nije ranjiva na prisluškivanje. No međutim, ovakav sustav i dalje ostaje ranjiv na aktivne oblike napada kao što je napad čovjekom u sredini.

2.1.2 Jednokratne lozinke

Jednokratne lozinke razvijene su u svrhu sprječavanja problema koji se javljaju prilikom ponovnog korištenja lozinke. Postoje dvije vrste jednokratnih lozinki:

izazov-odgovor lozinka,

lista lozinki.

Izazov-odgovor lozinka odgovara sa izazovom nakon primanja korisnikova identifikatora. Odgovor se izračunava ili iz odgovorene/povratne vrijednosti koristeći nekakvu elektroničku napravu ili se odabire iz tablice temeljene na izazovu.

Jednokratnu listu lozinki čine lozinke koje sekvencijalno koristi korisnik koji čeka za prijavu u sustav. Vrijednosti se izračunavaju na način da je teško pogoditi slijedeću vrijednost na temelju poznavanja prethodne.

Važno je spomenuti da se korištenjem autentifikacije lozinkom autentificira samo klijentska strana (strana koja se prijavljuje na sustav), dok se sustav na koji se prijavljuje ne autentificira ni na koji način. Samim time sustav ostaje ranjiv na lažiranje i napad čovjekom u sredini.

2.1.3 Kriptografija javnog ključa

Kriptografija javnog ključa temeljena je na vrlo kompleksnim matematičkim problemima koji zahtijevaju specijalizirano znanje. Kriptografija javnog ključa koristi dva ključa: tajni i javni. Ključevi su povezani s ekstremno kompleksnim matematičkim izračunom. Tajni ključ korišten je u postupku dekriptiranja, ali i u postupku kriptiranja poruka između naprava u komunikaciji. Prilikom kriptiranja i verifikacije potpisa koristi se javni ključ.

Prednost kriptografije javnog ključa očituje se u dostupnosti javnog ključa javnosti. Javni ključevi često se objavljuju u direktorijima na internetu kako bi se lakše dohvatili.

Integritet javnog ključa je od granične važnosti. Integritet javnog ključa osiguran je završetkom procesa certificiranja od strane službe ovjeravanja (engl. „Certification Authority“ - CA). Nakon što je služba ovjeravanja potvrdila valjanost dokumenata koje štiti javni ključ, služba ovjeravanja digitalno potpisuje ključ te korisnici koji pristupaju materijalima koje ključ štiti znaju da su isti certificirani.

Proces autentifikacije javnim ključem uključuje slijedeće korake:

1. Klijent odabire slučajne brojeve i rezultat šalje poslužitelju u poruci: „Poruka 1“.

2. Poslužitelj kao odgovor na primljenu poruku, šalje klijentu različite slučajne brojeve.

3. Klijent izračunava novu vrijednost, te poslužitelju šalje „Poruku 2“.

4. Poslužitelj koristi javni ključ klijenta kako bi potvrdio da su vraćene vrijednosti mogle biti izračunate koristeći samo tajni ključ.

Navedeni postupak autentificira klijenta. Ukoliko klijent želi autentificirati poslužitelja, izvode se isti koraci, ali sa zamijenjenim ulogama.

2.1.4 Dokazi „bez znanja“

Dokazi „bez znanja“ (engl. „zero - knowledge proofs“) omogućuju da računalo domaćin uvjeri drugo računalo da mu dopusti pristup bez otkrivanja bilo kakvih povjerljivih informacija. Računala koja sudjeluju u ovakvom obliku autentifikacije uobičajeno komuniciraju nekoliko puta kako bi izvršili postupak autentifikacije.

Klijent kreira teško rješiv problem i rješava ga pomoću informacija koje posjeduje. Klijent potvrđuje rješenje koristeći bit-obvezujuću shemu te šalje problem i potvrdu poslužitelju.

Poslužitelj šalje upit klijentu kako bi dokazao da su problemi povezani ili otvara potvrdu problema i potvrđuje da je to rješenje. Klijent je usuglašen sa zahtjevom.

Potrebno je oko desetak uspješno izmijenjenih poruka prije nego li je postupak autentifikacije uspješno završen i pristup odobren.

Dokaz „bez znanja“ može biti izveden i bez međusobne interakcije između klijenta i poslužitelja. U takvoj izvedbi klijent šalje poruke poslužitelju, ali ne i obratno. Ova metoda koristi jednosmjernu funkciju sažetka gdje se potvrđeni odgovori temelje na izlaznoj vrijednosti te funkcije. Broj potrebnih dokaza je veći od prethodnog slučaja (64 i više).

Dokaz identiteta „bez znanja“ ima mnogo ranjivosti i problema. Jedan od najvećih problema jest slijedeći: dok računalo domaćina A misli da dokazuje svoj identitet računalu B, moguće je da se računalo B istovremeno autentificira računalu C koristeći akreditiv računala A.

2.1.5 Digitalni potpis

U mnogim slučajevima nije potrebno da se autentificiraju strane koje žele međusobno komunicirati, primjerice prilikom skidanja nadogradnji i sigurnosnih zakrpa sa Interneta. Poslužitelj ne mora nužno znati tko skida programe. Klijent ne mora nužno brinuti o tome sa kojeg poslužitelja skida programe. Ipak, klijent želi biti siguran da su podaci koje skida autentični, a ne trojanski konj ili slične štetne informacije i programi. U ovakvome slučaju, digitalni potpis predstavlja najbolji način autentifikacije podataka koje korisnik želi skinuti.

Digitalni potpis je sažetak izračunat iz potpisanog dokumenta (pomoću jednosmjerne funkcije za izračun sažetka) koji je potom potpisan odnosno kriptiran tajnim ključem. Klijent verificira potpisani sažetak dekriptirajući ga javnim ključem poslužitelja te uspoređujući ga sa sažetkom izračunatim iz primljene poruke. Potpis također može biti korišten od strane poslužitelja kako bi verificirao podatke koje mu šalje klijent.

2.2 Pregled autentifikacijskih protokola

2.2.1 „Secure Sockets Layer“

Ovaj protokol služi za pouzdanu identifikaciju dva sugovornika povezana preko računalne mreže i zaštićeni prijenos podataka među njima. SSL je protokol za sigurno slanje poruka (komuniciranje) putem Interneta koji omogućuje slanje povjerljivih podataka putem Interneta u kriptiranom i sigurnom modu.

SSL radi na sljedeći način: nakon što je uspostavljena TCP konekcija klijent šalje inicijalnu poruku, na koju poslužitelj odgovara sa svojom inicijalnom porukom. Inicijalne poruke koriste se za uspostavljanje parametara konekcije koji uključuju: vrstu protokola, identifikator sjednice, korišteni način kriptiranja te metodu kompresije uz slučajne vrijednosti za klijenta i poslužitelja.

Nakon što se razmijenjene inicijalne poruke poslužitelj šalje svoj certifikat. Nakon autentifikacije poslužitelja, ovisno o korištenom načinu kriptiranja poslužitelj može zahtijevati certifikat klijenta. Nakon primitka inicijalne poruke, poslužitelj nalaže klijentu da počinje s kriptiranje i završi početno rukovanje. Potom može početi prijenos aplikacije.

Kada klijent i poslužitelj odluče nastaviti prethodnu sjednicu ili udvostručiti postojeću izmjenjuju se samo inicijalne poruke. Ukoliko poslužitelj ne pronađe povezujući identifikator sjednice pretpostavi da se radi o novoj. Prednost nastavljanja prethodne sjednice je u tome da čuva procesorsko vrijeme što može imati znatan učinak na performanse poslužitelja.

2.2.2 IP SEC

Zaglavlje autentifikacije omogućava strogu autentifikaciju i integritet datagrama (poruka UDP protokola). Ovisno o potpisivanju koje koristi, algoritam može omogućiti neopovrgavanje, isključujući područja koja su promijenjena prilikom slanja, kao što su „hop count“ ili „time to live“. Zaglavlje autentifikacije ima područja za slijedeće zaglavlje, duljinu korisnog sadržaja, indeks sigurnosnih parametara (identificira sigurnosnu vezu (engl. „Security Association“ - SA) između dva računala), redni broj i autentifikacijske podatke. Autentifikacija je neovisna o prijenosnom protokolu pa mogu postojati podaci iz više različitih protokola, na primjer TCP i UDP. Autentifikacijski podaci izračunati su korištenjem algoritam za izračun sažetka poruke.

Kako bi se izbjegli napadi 32-bitnom rednom broju nije dopušteno ulaziti u ciklički niz. Jednom mora uspostaviti novu sigurnosnu vezu i generirati nove ključeve. To se događa jednom u 232 paketa pa ako je 1460 bajta TCP dijelova preneseno, jedan može prenijeti 5.7 TB podataka koristeći samo jednu sigurnosnu vezu.

2.2.3 Sigurnosna ljuska

Sigurnosna ljuska (engl. „Secure Shell“ - SSH) je protokol za pružanje sigurnih udaljenih prijava i ostalih sigurnih mrežnih servisa preko nesigurne mreže.

Prilikom korištenja SSH svako računalo domaćina ima ključ pa tako prilikom uspostavljanja konekcije klijent može provjeriti pristupa li odgovarajućem poslužitelju. Ključeve poslužitelja moguće je spremati lokalno na računalu klijenta ili mogu biti podijeljeni koristeći protokol za podjelu ključeva.

Nakon uspostave pouzdanog toka bajtova između klijenta i poslužitelja dolazi na red autentifikacija računala domaćina koristeći funkcije transportnog sloja. Oba kraja šalju verziju identifikacije.

Razmjena ključeva počinje slanjem inicijalizacijskog paketa za razmjenu ključeva od strane klijenta i poslužitelja. Inicijalizacijski paket sadrži listu algoritama za razmjenu ključeva, ključeve, kriptiranje, MAC i podržanu razinu kompresije. Poslužitelj i klijent mogu dogovoriti različiti skup algoritama za svaki smjer toka podataka. Za svaku kategoriju odabire se najbolji algoritam podržan i od klijentske i poslužiteljske strane.

2.2.4 Kerberos

Kerberos autentifikacijski protokol počeo se razvijati 1978. godine na „Massachusetts Institute of Technology“ (MIT) u okviru projekta „Athena“. Naziv je dobio po troglavom psu „Kerberu“ iz grčke mitologije koji čuva ulaz u podzemni svijet „Had“. Koriste se dvije osnovne komponente:

ulaznica – koristi se za autentifikaciju korisnika i osiguravanje podataka,

autentifikator – kojim se potvrđuje da je korisnik isti onaj korisnik kojemu je ulaznica inicijalno dodijeljena.

Kada se korisnik prijavi u sustav, sustav se spaja na Kerberos poslužitelj od kojega dobiva sjednički ključ. Sjednički ključ korišten je između korisnika i poslužitelja za dodjelu ulaznica (engl. „Ticket Granting Server“ – TGS). Sjednički ključ kriptira se ključem temeljenim na korisnikovoj lozinci. Ukoliko korisnika daje pravu lozinku sustav je u mogućnosti dekriptirati sjednički ključ. Nakon toga, lozinka korisnika briše se iz memorije kako ne bi bila kompromitirana. Ulaznica prestaje biti važeća nakon nekog određenog vremena.

Ukoliko korisnik želi koristiti uslugu za koju nema ulaznicu, prvo je potrebno spojiti se na poslužitelj za dodjelu ulaznica od kojega dobiva ulaznicu koju je moguće koristit samo za pristup servisu koji pruža tu uslugu. Korisnik se tada može spojiti kroz kriptirani kanal na poslužitelj. Nakon što ulaznica prestane bit važeća, korisnik mora zatražiti novu.

Glavni problem kod Kerberos sustava jest brzi rast. Kerberos poslužitelj mora spremiti tajne ključeve za svakog korisnika i svaki poslužitelj za dodjelu ulaznica te samim time može postati vrlo kompleksan u implementacijama gdje je povjerenje između više organizacija jako bitno.

3 Digitalni identitet

Jednako kao što identiteti u stvarnom svijetu i digitalni identiteti dolaze u različitim oblicima. Pretpostavit ćemo da korisnik ima račun elektroničke pošte otvoren kod Yahoo-a identificirajući se preko adrese elektroničke pošte. Također može imati digitalne identitete kod različitih komercijalnih organizacija kao što su Amazon ili eBay zajedno s identitetom za Web stranice popularnog facebook-a. Svaki od tih identiteta identificiran je pomoću korisničkog imena koje korisnik sam odabire. Korisnik također može imat digitalni identitet dobiven kao zaposlenik neke tvrtke koji se koristi samo unutar granica mreže u vlasništvu te tvrtke.

Jednako kao u stvarnom svijetu dobro je koristiti različite digitalne identitete u različitim slučajevima. Svaki od njih koristi različite podatke. Identitetu koji se koristi na Amazonu dozvoljen je pristup broju kreditne kartice dok onom na facebook-u nije. Takva pravila čine digitalne identitete različitima.

3.1 Predstavljanje digitalnog identiteta sigurnosnim značkama

Unatoč njihovoj raznolikosti, digitalni identiteti imaju zajedničku jednu važnu stvar, a to je: kada se prenose na mreži, svaki digitalni identitet predstavlja neku vrstu sigurnosne značke. Sigurnosna značka samo je jedan skup bitova koji predstavlja informacije o digitalnom identitetu. Kao što je prikazano na slici 3.1, ove informacije sastoji se od jedne ili više tvrdnji, od kojih svaka sadrži neki dio ukupne prenijete informacije o tom identitetu. Jednostavna sigurnosna značka može sadržavati samo jednu tvrdnju, korisničko ime, dok složenija može sadržavati korisničko ime, prezime, kućnu adresu i dr. Sigurnosna značka za neke digitalne identitete također može uključivati i osjetljive informacije kao što su brojevi kreditnih kartica.

Slika 3.1 Sigurnosna značka

Kod najsigurnijih sigurnosnih značaka, neke informacije dostavljaju se u svrhu dokazivanja pripadnosti podataka korisniku koji ih predstavlja. Jedna jednostavna (i trenutno vrlo uobičajena) metoda je slanje lozinke uz podatke. Mnogo snažniji pristup je digitalno potpisivanje svih ili djela podataka pomoću privatnog ključa te osiguravanje odgovarajućeg javnog ključa u obliku certifikata.

Iako je osnovna ideja svake sigurnosne značke ista, ona je niz tvrdnji u obliku polja, koriste se različiti formati za njihovo predstavljanje. Najjednostavniji primjer je predstavljanje korisničkog imena kao teksta, dok bi složeniji oblik bio u obliku X.509 certifikata ili pak Kerberos ulaznice. Niti jedan od tih formata nije dizajniran kako bi omogućio transport proizvoljnog skupa polja no postoji nešto što je vrlo korisno za digitalne identitete. Značke stvorene korištenjem „Security Assertion Markup Language“ (SAML) jezika, standarda stvorenog od strane industrijske grupe „Oasis“ to omogućavaju. Na temelju XML-a, SAML jezik može se koristiti za definiranje proizvoljnih polja unutar sigurnosnih značaka.

Tradicionalno, digitalni identiteti prvenstveno su se koristili za autentifikaciju. Današnji najčešći oblici sigurnosnih značaka – korisničko ime, X.509 certifikat i Kerberos ulaznice odražavaju se na tu činjenicu tako što se informacije koje se prenose uglavnom koriste za provjeru autentičnosti jednog identiteta. Ali zbog čega se jedan digitalni identitet ne bi mogao koristiti na više različitih mjesta kao što je slučaj s fizičkim identitetom? Svaka kartica u novčaniku odražava neku vrstu identiteta i svaka od njih nosi i neke korisne druge korisne informacije. Na primjer vozačka dozvola uključuje ime, starosnu dob, sliku i neke druge informacije. Digitalni identitet koji potvrđuje ove informacije može biti iskorišten za razne stvari, kao što je dokazivanje da je osoba starija od 18 godina ili da osoba primjerice nosi naočale.

Iako su sigurnosne značke u prošlosti bile usmjerene na prijenos informacija korištenih pri autentifikaciji, važno je napomenuti da se pojam digitalnog identiteta ne odnosi samo na to. Informacije koje se nalaze na kreditnim karticama tipično se ne koriste za autentifikaciju samog korisnika, ali informacije koje ta kartica prenosi kao što je primjerice kreditni broj mogu biti korisne. Korištenjem SAML jezika moguće je definirati sigurnosne značke koje sadržavaju velik broj proizvoljnih, korisnih informacija. Digitalni identiteti mogu postati široko korišteni u mrežnom svijetu kao što su fizički identiteti široko korišteni u stvarnom svijetu.

3.2 Korištenje digitalnog identiteta: Windows CardSpace i metasustav identiteta

Postojanje različitih oblika digitalnog identiteta nužno je. Realnost je takva da su ti identiteti pribavljeni iz različitih izvora. To znači da rješenje ne može biti vezano uz jedan sustav digitalnog identiteta nego treba pronaći jedinstven način korištenja velikog broja sustava digitalnog identiteta. U tom slučaju potreban je sustav sustava – metasustav, zasnovan na identitetu.

Stvaranje metasustava identiteta zahtjeva suradnju više organizacija. Jedna organizacija ne može samostalno uvesti rješenje. Na sreću postoje slobodni komunikacijski standardi koji mogu biti iskorišteni za ovo pitanje. Zasnovani na SOAP-u i XML-u, ti standardi uključuju „WS-Security“, „WS-Trust“, „WS-MetadataExchange“, i „WS-SecurityPolicy“ protokole. Korištenjem tih protokola moguće je definirati konzistentan način rada s digitalnim identitetima stvorenim od strane različitih izvora korištenjem bilo koje tehnologije.

U suradnji s ostalima, Microsoft je imao vodeću ulogu u definiranju tih normi zasnovanih na metasustavu identiteta. Također je dodao u svoj Windows operacijski sustav podršku koja omogućava korištenje metasustava identiteta. Windows CardSpace, originalnog kodnog imena „InfoCard“, pruža korisnicima jedinstven način rada s digitalnim identitetima.

Naravno, ovakvo rješenje ne može uspjeti ukoliko ga druge organizacije također ne implementiraju.

U svibnju 2005. godine, Microsoft je uveo svoju viziju metasustava identiteta kako bi smanjio složenosti i rizike vezane uz upravljanje i razmjenu digitalnih identiteta.

Ova vizija objašnjava suradnju na temelju zajedničkih standarda kao što su „WS-Security“, „WS-Trust“, „WS-MetadataExchange“, i „WS-SecurityPolicy“ i drugi „WS-*“ protokoli. Ovi protokoli omogućavaju aplikacijama i servisima sigurnu razmjenu sigurnosnih zahtjeva putem sigurnosne politike te siguran prijenos digitalnih identiteta. Windows CardSpace, izdan sa sustavom Windows Vista i Microsoft .NET Framework 3.0, igra važnu ulogu u metasustavu identiteta. Jedna od uloga je zamjenjivanje tradicionalne metode autentifikacije putem korisničkog imena i lozinke kao alat koji omogućuje korisnicima bolje upravljanje digitalnim identitetima i pomaže u zaštiti od različitih oblika napada na korisnički identitet kao što je primjerice „phishing“.

Život bi mogao biti mnogo jednostavniji kada bi bilo moguće korištenje jednog digitalnog identiteta predstavljenog jednom sigurnosnom značkom za sve potrebe. Zbog korištenja različitih identiteta u fizičkom svijetu i u digitalnom svijetu potrebno je uvijek imati različite identitete. Ponekad postane vrlo teško stvaranje, korištenje i upravljanje velikim brojem različitih digitalnih identiteta na jednostavan, razumljiv i učinkovit način.

Točno tom problemu pristupa metasustav identiteta. Umjesto izmišljanja još jedne tehnologije za stvaranje i predstavljanje digitalnog identiteta, metasustav identiteta nudi dosljedan način upravljanja s više digitalnih identiteta, bez obzira na vrstu korištenih sigurnosnih značaka. Korištenjem standardnih protokola koji omogućavaju implementaciju na bilo kojoj platformi, metasustav identiteta omogućuje korištenje proizvoljnih oblika sigurnosnih značaka za prenošenje identiteta.

Osim pružanja jednostavnog načina odabira identiteta korisniku, Windows CardSpace igra važnu ulogu u metasustavu identiteta.

3.3 Što sve Windows CardSpace pruža?

Postoje četiri bitna aspekta CardSpace tehnologije:

podrška za bilo koji sustav digitalnog identiteta,

konzistentna kontrola digitalnog identiteta,

nadomjestak standardne metode autentifikacije na Webu zasnovane na lozinci,

povećano povjerenje u identitet udaljenih aplikacija.

3.3.1 Podrška za bilo koji sustav digitalnog identiteta

Višestruki digitalni identiteti koji se koriste obično dolaze iz različitih izvora sustava digitalnih identiteta izraženi korištenjem različite tehnologije. Bez obzira na raznolikost sustav se može razložiti na tri različite uloge:

Korisnik (subjekt) - Entitet povezan s digitalnim identitetom. Digitalni identitet ne mora nužno biti povezan samo s ljudima. Identitet može predstavljati organizacije, programe, računala i dr.

Izdavatelj identiteta (engl. „Identity Provider“ - IP) - Izdavatelj identiteta je upravo ono što samo ime sugerira. On pruža digitalni identitet za korisnika. Digitalni identitet izdan od strane različitih izdavatelja identiteta različitih pružatelja usluga može nositi različite informacije i pružati različite razine osiguranja točnosti korisnikovih podataka

Pouzdajuća strana (engl. „Relying Party“ - RP) - Aplikacija koja se na neki način oslanja (pouzdaje) na digitalni identitet. Pouzdajuća strana često koristiti identitet za autentifikaciju korisnika.

Nakon spominjanja uloga u CardSpace sustavu pojašnjeno je na koji način spomenute tri strane surađuju.

Slika 3.2 Interakcija između tri strane

Slika 3.2 prikazuje interakciju između spomenute tri strane: korisnika, izdavatelja identiteta i pouzdajuće strane. Korisnik se oslanja na neki program koji podržava CardSpace, kao što je Web preglednik za pristup nekoj pouzdajućoj strani. Osnovna komunikacija između te tri strane sastoji se od sljedeća tri koraka:

1. Aplikacija dobiva od pouzdajuće strane sigurnosne zahtjeve ovisno o pouzdajućoj strani kojoj korisnik želi pristupiti. Ova informacija definirana je u obliku sigurnosne politike. Ti zahtjevi uključuju: format sigurnosne značke te podatke koje ta značka mora sadržavati.

2. Nakon što je aplikacija prikupila zahtjeve o sigurnosnoj značci, prosljeđuje ih CardSpace-u tražeći od njega odgovarajuću sigurnosnu značku od odgovarajućeg izdavatelja identiteta.

3. Nakon što je CardSpace pribavi, sigurnosna značka prosljeđuje se aplikaciji koja ju šalje pouzdajućoj strani. Ona ju zatim koristi za autentifikaciju korisnika.

Prethodni grubi opis opisuje najvažnije aspekte procesa koji uključuju:

Windows CardSpace i metasustav identiteta u potpunosti su neovisni o formatu sigurnosne značke. CardSpace obično nije niti svjestan formata sigurnosne značke te je zbog toga unutar CardSpace-a moguć rad s bilo kojim sustavom digitalnih identiteta, korištenjem bilo koje vrste sigurnosne značke, uključujući korisnička imena, X.509 certifikate, Kerberos ulaznice, SAML značke ili nešto treće. To omogućava zajedničko korištenje CardSpace-a i metasustava identiteta bez obzira o kojoj se tehnologiji digitalnog identiteta radi. Omogućena je također i podrška za sustave digitalnih identiteta koji bi se mogli pojaviti u budućnosti.

Sve razmjene definirane unutar metasustava identiteta implementirane u CardSpace-u zasnovane su na otvorenim protokolima. U najopćenitijoj situaciji sigurnosna politika pouzdajuće strane opisana je pomoću „WS-SecurityPolicy“ protokola. Sigurnosna politika preuzima se korištenjem „WS-MetadataExchange“ protokola. Sigurnosna značka dobiva se korištenjem „WS-Trust“ protokola i prenosi pouzdajućoj strani korištenjem „WS-Security“ protokola.

U jednostavnijem (i vjerojatno najuobičajenijem) scenariju Web preglednik komunicira s Web stranicom preuzimajući sigurnosnu politika izraženu pomoću HTML-a. Sigurnosna politika i sigurnosna značka razmjenjuje se sa Web stranicom korištenjem HTTPS protokola. Iako interakcije s izdavateljem identiteta i dalje ovisi o „WS-Trust“ protokolu, Web stranica nije obavezna implementirati niti jednu od WS-* specifikacija kako bi sudjelovala u ulozi pouzdajuće strane.

3.3.2 Konzistentna kontrola digitalnog identiteta

Posjedovanje standardnih protokola za stjecanje i prenošenje sigurnosnih značaka svakako je korisno. Ipak sustav prije svega mora biti jednostavan i jasan za korištenje kako bi korisnicima olakšao rukovanje. U skladu s tim, jedan od primarnih ciljeva CardSpace-a i metasustava identiteta je olakšavanje korištenja svim korisnicima od običnih korisnika pa sve do sigurnosnih stručnjaka. Za ostvarenje tog cilja CardSpace implementira jednostavno i intuitivno korisničko sučelje za rad s digitalnim identitetima. Slika 3.3 prikazuje izgled sučelja za odabir digitalnog identiteta.

Slika 3.3 CardSpace selektor identiteta

Kao što slika 3.3 ilustrira, svaki digitalni identitet prikazuje se kao informacijska kartica (engl. „InfoCard“). Svaka kartica predstavlja digitalni identitet koji korisnik može poslati pouzdajućoj strani. Osim vizualne reprezentacije kao što je prikazano na slici, svaka kartica također sadrži i informacije o pojedinom digitalnom identitetu. Te informacije uključuju: informacije o izdavatelju identiteta koji je zadužen za izdavanje pripadajuće sigurnosne značke, tip značke koju izdavatelj identiteta može izdati te podatke koje sigurnosna značka može sadržavati. Odabirom određene kartice, korisnik izdaje zahtjev za posebnom sigurnosnom značkom koja sadržava određeni skup tvrdnji prijavljenih od strane izdavatelja identiteta. Ova tehnička složenost skrivena je od korisnika. Slika 3.4 koja predstavlja proširenu verziju slike 3.2, prikazuje u kom je trenutku bitna korisnikova odluka o odabiru identiteta.

Slika 3.4 Odabir identiteta

Kao što je ranije opisano, proces započinje zahtjevom aplikacije za sigurnosnom politikom pouzdajuće strane. Podsjećamo da je unutar sigurnosne politike zapisano kakav tip sigurnosne značke ona zahtjeva te koje podatke sigurnosna značka mora sadržavati. Nakon što aplikacija pribavi sigurnosnu politiku, ista se predaje CardSpace-u i sustav prikazuje selektor identiteta s karticama koje zadovoljavaju sigurnosnu politiku. Kada korisnik pritisne na određenu karticu, CardSpace šalje zahtjev izdavatelju identiteta povezanim s tom karticom. Izdavatelj identiteta zatim vraća sigurnosnu značku koja se prosljeđuje pouzdajućoj strani.

Pružanje konzistentnog načina odabira identiteta bitno je iz dva razloga:

Korisnik ima dosljedan način korištenja svog digitalnog identiteta što smanjuje zbunjenost korisnika i broj pogrešaka. Svaka aplikacija koja koristiti CardSpace koristit će isti mehanizam za rad s digitalnim identitetima.

Korisnici ne moraju biti upoznati sa sigurnosnom tehnologijom koja se koristi u pozadini. Oni ne trebaju znati je li određeni identitet predstavljen sigurnosnom značkom izražen korištenjem X.509 certifikata, SAML-a ili na neki drugi način. Pružajući jednaku vizualnu reprezentaciju, CardSpace izbjegava zamaranje korisnika s nepotrebnom složenosti.

3.3.3 Nadomjestak standardne metode autentifikacije na Webu zasnovane na lozinci

Korisničko ime danas je najčešći tip sigurnosne značke na Internetu. Način dokazivanja pripadanja korisničkog imena korisniku odnosi se na upisivanje lozinke povezane s korisničkim imenom. Najčešće korisničko ime i pripadajuću lozinku korisnik odabire sam. Pri upisivanju podataka na stranice koristi se SSL protokol čime se osigurava kriptiranje čitave komunikacija što otežava napadačima dolazak do tih podataka. Iako se ovakav način autentifikacije čini vrlo sigurnom on je ranjiv na drugi oblik napada: „phishing“. Kako bi se poboljšala sigurnost Web prijave u cjelini, CardSpace omogućuje zamjenu autentifikacije zasnovane na lozinci jačim mehanizmima autentifikacije. Umjesto autentifikacije korisnika lozinkom Web stranice mogu koristiti autentifikaciju zasnovanu na sigurnosnim značkama. Primjerice tvrtka koja posjeduje velik broj Web stranica može nuditi i svoj izdavatelj identiteta za izdavanje značaka koje će biti prihvaćene na tim Web stranicama. Ovaj pristup minimizira korištenje lozinke. Ipak, to je primjenjivo samo za određeni dio Web stranica, budući da ne postoji jedinstveni izdavatelj identiteta za izdavanje značaka koje bi bile prihvaćene na svim Web stranicama.

Postavlja se pitanje kako riješiti slučajeve u kojima korisnik sam odabire svoje korisničko ime i lozinku. Taj pristup danas je najšire korišteniji na Webu zbog svoje jednostavnosti: nije potrebna treća strana za stvaranje korisničkog imena i lozinke. Ipak ovaj pristup ne nudi mnogo osiguranja da je korisnik onaj za kojeg se on predstavlja, budući da stranica ne može znati da li je ime koje korisnika pruža zaista njegovo. Ipak stranicama koje koriste ovaj pristup obično su ti podaci potrebni samo za prepoznavanje određenog korisnika svaki put kada se on prijavi. Sve to zahtijeva jedinstven digitalni identitet korisnika ne nužno s točnim podacima o njemu. Kako bi riješio taj problem, CardSpace unutar sebe uključuje lokalni izdavatelj identiteta. Kao što prikazuje slika 3.5, lokalni izdavatelj identiteta radi na lokalnom Windows sustavu i može stvoriti informacijske kartice. Na primjeru prikazanom na slici 3.5, korisnik ima tri kartice koje su izdane od vanjskog izdavatelja identiteta zajedno s jednom karticom izdanom od lokalnog izdavatelja identiteta.

Informacijske kartice izdane od lokalnog izdavatelja identiteta mogu sadržavati samo osnovne informacije, kao što su korisničko ime, poštansku adresu, adresa elektroničke pošte i telefonski broj. Kada korisnik odabere jednu od ovih tipova kartica lokalni izdavatelj identiteta generira SAML značku koja sadrži informacije o korisniku koje su unesene prilikom stvaranja kartice. Lokalni izdavatelj identiteta dodatno generira par javni/privatni ključ te potpisuje sigurnosnu značku privatnim ključem. Kako bi se spriječilo da istu sigurnosnu značku napadač upotrijebi kasnije, sigurnosna značka sadrži vremensku oznaku (engl. „Timestamp“) i druge informacije koje omogućavaju korištenje značke samo od izvornog korisnika. Aplikacija zatim šalje potpisanu značku, zajedno sa svojim javnim ključem pouzdajućoj strani. Pouzdajuća strana može javnim ključem provjeriti valjanost digitalno potpisane sigurnosne značke. Kako bi se onemogućilo praćenje aktivnosti korisnika na Webu preko javnog ključa lokalni izdavatelj identiteta stvara različite parove ključeva za svaku pouzdajuću stranu kojoj se pristupa tom karticom.

Slika 3.5 Korisnik s informacijskom karticom izdanom od lokalnog izvatelja identiteta

3.3.4 Povećano povjerenje u identitet udaljenih aplikacija

Smanjujući oslanjanje Web stranica na autentifikaciju zasnovanu na lozinci može pomoći pri smanjenju broja napada krađe identiteta, ali to neće u potpunosti eliminirati problem. Primjerice napadač može navesti korisnika da posjeti njegovu stranicu koja prihvaća bilo koji oblik sigurnosne značke, upravljačke ili osobne kartice te zatim tražiti informacije kao što su broj kreditne kartice. Srž spomenutog problema je korisnikova nemogućnost razlikovanja prave stranice od stranica stvorenih od napadača. Obje stranice mogu prikazivati iste logotipe i druge grafičke objekte. Oba mogu koristiti čak i sigurnu SSL komunikaciju, jer napadač može izraditi certifikat kao i bilo tko drugi. Ako korisnik pritisne na link naveden u napadačevoj spam poruci vezanoj uz banku, naći će se na stranici koja izgleda baš kao i stranica njegove banke. Kao što je spomenuto komunikacija i dalje može biti pomoću SSL protokola.

Rješavanje ovog problema zahtjeva dvije stvari:

poboljšanjem jamstva kojim stranica dokazuje svoj identitet korisnicima,

upoznavanjem korisnika o jamstvu koje stranica nudi kao dokaz svog identiteta.

Windows CardSpace i metasustav identiteta podržavaju oba zahtjeva.

Rješavanje prvog problema ovisi o poboljšanju certifikata koji se koriste za to. Danas, Web stranice obično dokazuju svoj identitet certifikatima koje koriste za SSL komunikaciju. Ovo je bolje nego ništa, ali zapravo SSL certifikati dokazuju samo da neka stranica posjeduje određeno DNS ime. Nema garancije da to ime odgovara informacijama prikazanim na toj stranici. Napadač može koristiti certifikat izdan za DNS ime koje on posjeduje, na primjer, za sigurnu komunikaciju njegovom stranicom koja je pažljivo stvorena tako da izgleda baš kao i stranica neke banke. SSL certifikati nisu dovoljni za rješavanje tog problema.

Kako bi riješio taj problem, Microsoft je u suradnji s drugim organizacijama kreirao novu razinu certifikata. Novi certifikati sadržavaju više informacija od tradicionalnih SSL certifikata, uključujući ime, lokaciju i logotip organizacije za koju se certifikat izdaje. Ove certifikate mogu koristiti i izdavatelj identiteta i pouzdajuće strane za dokazivanje njihova identiteta korisnicima CardSpace aplikacije.

Stvaranje sigurnijih certifikata odnosi se na prvi od dva maloprije spomenuta zahtjeva. Bez obzira na sigurnije certifikate korisnik i dalje treba donijeti odluku o povjerenju nekoj Web stranici. CardSpace zahtijeva od korisnika da odobri korištenje izdavatelja identiteta i pouzdajuće strane kojoj pristupa. Kada se informacije o kartici prvi put instaliraju na korisnikov sustav, korisnika se pita prihvaća li sigurnosnu značku od izdavatelja identiteta koji je izdao tu karticu. Isto tako, prilikom prvog posjeta nekoj Web stranici od korisnika se zahtijeva da potvrdi svoju suglasnost o slanju digitalnog identiteta toj stranici. Slika 3.6 prikazuje primjer kako izgleda ekran koji od korisnika zahtjeva da potvrdi svoju suglasnost o slanju digitalnog identiteta:

Slika 3.6 Potvrđivanje suglasnosti o slanju digitalnog identiteta

Kao što ovaj primjer pokazuje, sigurniji certifikat sadržava ime, lokaciju, URL Web stranice i logotip organizacije. Uz logotip organizacije može biti prikazan naziv i logotip organizacije koja je provjerila te informacije (kao što je „VeriSign“). Ovi podaci pokazuju da korisnik ovoj organizaciji treba pristupiti s više povjerenja. Ukoliko se koristi obični SSL certifikat korisnik će biti upozoren o nižoj razini povjerenja koju ta stranica nudi. Cilj je pomoći korisnicima u donošenju informirane odluke o izdavatelju identiteta i o stranicama kojima korisnik šalje svoj digitalni identitet. Treba napomenuti da korisnik samo prilikom prvog pristupa stranici ili izdavatelju identiteta mora potvrditi svoje vjerovanje.

3.4 Windows CardSpace i informacijske kartice

Kao što je već spomenuto unutar metasustava identiteta, postoje tri ključna sudionika: pouzdajuća strana (engl. „Relying Party“ - RP), korisnik (subjekt), i izdavatelj identiteta (engl. „Identity Provider“ - IP).

Pouzdajuća strana može biti aplikacija ili Web stranica koji prihvaća sigurnosnu značku (engl. „Security token“) kako bi izvršio određeni zadatak.

Subjekt je osoba koji želi sigurno predstaviti informacije (kao što su identifikacijski podaci) pouzdajućoj strani. Te informacije dostavljaju se u obliku sigurnosne značke koju je izdao neki izdavatelj identiteta kao što su banke, poslodavci, vlade i sl.

Izdavatelj identiteta odgovoran je za izdavanje sigurnosnih značaka na zahtjev subjekta, jamčeći za ispravnost i točnost korisnikovih podataka sadržanih unutar značke. Pružatelj identiteta ostvaren je kao servis sigurnosnih značaka (engl. „Security Token Service“ - STS), Web servis koji implementira „WS - Trust“ protokol omogućavajući izdavanje, obnavljanje, potvrđivanje ili otkazivanje sigurnosnih značaka.

Slika 3.7 Sudionici metasustava identiteta

Slika 3.7 prikazuje odnos između tri sudionika. Pouzdajuća strana oslanja se na točno određenu vrstu sigurnosnih značaka za autorizaciju poziva. Izdavatelj identiteta autentificira subjekt i izdaje mu točno određenu vrstu sigurnosne značke koju zahtjeva pripadajuća pouzdajuća strana. Subjekt zatim šalje tu značku, koja sadrži sve potrebne korisnikove podatke pouzdajućoj strani. Razdvajanje uloga i korištenje međusobno usklađenih protokola definirani su metasustavom identiteta. Svaki sudionik može biti implementiran uporabom različite tehnologije, na različitoj platformi sve dok se komunikacija odvija u skladu s odgovarajućim Web i WS-* protokolima.

U kontekstu metasustava identiteta Windows CardSpace ima dvije uloge. Prvo, to je klijentska tehnologija koja se koristi za stvaranje, upravljanje i odabirom digitalnih identiteta na siguran i dosljedan način. Drugo, to je lokalni izdavatelj identiteta koji može generirati sigurnosne značke.

Digitalni identitet predstavljen je u obliku informacijske kartice. Windows CardSpace omogućava korisnicima stvaranje osobnih kartica ili uključivanje upravljačkih kartica generiranih od strane nekog drugog pružatelja identiteta. Korisnik kasnije može odabrati karticu koju želi poslati nekoj od pouzdajućih strana. Kartica koju korisnik želi poslat mora zadovoljavat potrebe te pouzdajuće strane, odnosno sadržavat polja koja ta strana zahtjeva. Pri tom se može koristiti osobna kartica za prezentiranje osobnih podataka te ukoliko je potrebno i upravljačka kartica kako bi se prezentirali dodatni podaci specifični za tu pouzdajuću stranu.

4 Informacijske kartice

Kim Cameron je pretpostavila da mora postojati skup objektivnih zakona koji određuju hoće li neki sustav identiteta uspjeti ili ne u danom kontekstu. Bez obzira na to kako organizacija pozicionira sustav identiteta, ukoliko prekrši ove zakone, vrlo vjerojatno će na neki način doći do neuspjeha. Možda će neuspjeh biti kršenje sigurnosti, dopuštajući podvale kao što je krađa identiteta ili će ljudi jednostavno odbiti takav sustav jer se u njemu ne osjećaju ugodno. Bez obzira na razloge, arhitekti informacijskih kartica misle da neće uspjeti ukoliko se ne budu pridržavali tih zakona.

4.1 Sedam zakona uspješnog sustava identiteta

Sljedeći zakoni oblikuju dizajn i implementaciju informacijskih kartica. Arhitekti informacijskih kartica ne vjeruju da sustav koji ne poštuje ove zakone može preživjeti.

4.1.1 Kontrola i dozvola korisnika

Korisnik bi trebao imati mogućnost kontrole informacija i odluku koje bitove informacija želi objaviti drugoj strani.

4.1.2 Minimalno razotkrivanje

Niti jedan sustav koji traži osobne informacije nije 100% siguran. Otkrivanjem većeg broja informacija raste izloženost krađi identiteta i drugim napadima. Stabilni sustavi identiteta ne otkrivaju više informacija nego što je potrebno u danom kontekstu i koriste identifikatore dizajnirane za specifični kontekst. Primjerice, ako je slučaj odjava knjige iz lokalne knjižnice, nije potrebno priložiti broj socijalnog osiguranja jer knjižnica izdaje svoj vlastiti jedinstveni identifikator.

4.1.3 Opravdane stranke

Prilikom prijave socijalnoj službi ima smisla priložiti osobnu iskaznicu, ali prilikom kockanja na Internetu ne. U tom se slučaju koristi drugi identitet. Sve prisutne stranke trebaju imati opravdani razlog za sudjelovanje u transakciji. Moguće je koristiti Microsoft lozinku sa pohranjivanje MSDN sadržaja, ali je bolje ne koristiti je za „PayPal“ račun.

4.1.4 Usmjereni identitet

Postoji mnogo javnih subjekata koji moraju imati mogućnost lakog otkrivanja. „Amazon.com“ ima mogućnost lakog otkrivanja. On predstavlja i širi svoj identitet svijetu putem SSL certifikata. No međutim, prilikom pristupa na „Amazon.com“ očekuje se korištenje privatnog identifikatora za praćenje aktivnosti korisnika.

4.1.5 Pluralizam operatora i tehnologija

Ne postoji sustav identiteta koji je zadovoljavajući u svakom kontekstu i niti jedan pružatelj identiteta nije opravdan u svim slučajevima. Kako bi bio uspješan, sustav mora omogućiti zajednički rad mnogih pružatelja identiteta i tehnologija. Niti jedan sustav identiteta nije dominantan, ali može postojati sustav sustava koji korisnicima predstavlja jedinstvenu apstrakciju.

4.1.6 Ljudska integracija

Krajnji korisnik mora biti razmatran u krajnjoj točci protokola autentifikacije. Kao industrija, učinjen je fantastičan posao osiguravanja poruka koje putuju preko bakrenih žica dugačkih tisuće kilometara. To je posljednjih nekoliko stopa između računalne konzole i čovjeka gdje se događa najviše loših stvari. „Phishing“ i drugi socijalno inženjerski napadi eksploatiraju ranjiva korisnička sučelja. Stabilni sustav identiteta smanjuje te prijetnje do najmanje moguće mjere.

4.1.7 Dosljedno iskustvo

Stabilni identitet sustava dosljednom korisniku predstavlja lako razumljivu apstrakciju, bez obzira na prisutnu tehnologiju i pružatelja identiteta. Korisnik mora biti sposoban odabrati odgovarajući identitet za dani slučaj i trebao bi djelovati kao pravi. Digitalni identitet korisniku ne bi trebao biti apstraktan. Trebao bi ga doživljavati konkretnim, kao i člansku iskaznicu u svome džepu.

Svaka kartica predstavlja važne informacije o svom izdavatelju identiteta koje uključuju:

URL servisa sigurnosnih značaka izdavatelja identiteta. Pomoću te informacije, kad korisnik selektira karticu kako bi se autentificirao na neku Web stranicu, Windows CardSpace zna na koji URL treba poslati zahtjev za sigurnosnom značkom koja sadrži odgovarajuća polja.

Tipove polja vezanih uz karticu. Kako izdavatelj identiteta izdaje karticu on definira i polja koja kartica predstavlja. Pouzdajuća strana specificira koja polja su potrebna za uspješnu autentifikaciju i samo kartice koje predstavljaju ta polja mogu biti odabrane od strane korisnika.

Tip sigurnosne značke koju izdavatelj identiteta može izdati. Pouzdajuća strana specificira koje tipove sigurnosnih značaka podržava te samo značke tog tipa mogu biti odabrane od strane korisnika.

Kartica izdana od izdavatelja identiteta može biti serijalizirana kao potpisani XML dokument sa „.crd“ ekstenzijom. Ta datoteka sadrži <InformationCard> rubriku unutar koje su zapisane informacije potrebne Windows CardSpace-u. Ovako izgleda izvorni XML potpisane upravljačke kartice uključene u Windows CardSpace:

<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

<dsig:SignedInfo>...</dsig:SignedInfo>

<dsig:SignatureValue>...</dsig:SignatureValue>

<dsig:KeyInfo>...</dsig:KeyInfo>

<dsig:Object Id="_Object_InfoCard">

<ic:InformationCard xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity"

xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex"

xmlns:wsa="http://www.w3.org/2005/08/addressing"

xmlns:wsid="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"

xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xml:lang="en-us">

<ic:InformationCardReference>

<ic:CardId>

http://www.samplesite.com/card/ED18504F-40B9-5A58-C200-761DC886DF29

</ic:CardId>

<ic:CardVersion>1</ic:CardVersion>

</ic:InformationCardReference>

<ic:CardName>thatindigogirl</ic:CardName>

<ic:CardImage MimeType="image/png">

[base64 encoded image]

</ic:CardImage>

<ic:Issuer>http://www.samplesite.com/tokenissuer.svc</ic:Issuer>

<ic:IssuerName>That Indigo Girl</ic:IssuerName>

<ic:TimeIssued>2006-12-29T22:32:17Z</ic:TimeIssued>

<ic:TimeExpires>9999-12-31T23:59:59.9999999Z</ic:TimeExpires>

<ic:TokenServiceList>

<ic:TokenService>

<wsa:EndpointReference>

<wsa:Address>

http://www.samplesite.com/sts/tokenissuer.svc

</wsa:Address>

<wsa:Metadata>

<mex:Metadata>

<mex:MetadataSection>

<mex:MetadataReference>

<wsa:Address>

http://www.samplesite.com/sts/mex

</wsa:Address>

</mex:MetadataReference>

</mex:MetadataSection>

</mex:Metadata>

</wsa:Metadata>

<wsid:Identity>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>[base64 encoded certificate of the IP]

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</wsid:Identity>

</wsa:EndpointReference>

<ic:UserCredential>

<ic:UsernamePasswordCredential>

<ic:DisplayCredentialHint>

Please enter your password

</ic:DisplayCredentialHint>

<ic:Username>thatindigogirl</ic:Username>

</ic:UsernamePasswordCredential>

</ic:UserCredential>

</ic:TokenService>

</ic:TokenServiceList>

<ic:SupportedTokenTypeList>

<wst:TokenType>

urn:oasis:names:tc:SAML:1.0:assertion

</wst:TokenType>

</ic:SupportedTokenTypeList>

<ic:SupportedClaimTypeList>

<ic:SupportedClaimType Uri=

"http://schemas.xmlsoap.org/ws/2005/05/identity/

claims/personalprivateidentifier">

<ic:DisplayTag>PPID</ic:DisplayTag>

<ic:Description>Unique identifier for the card</ic:Description>

</ic:SupportedClaimType>

...other claim types

</ic:SupportedClaimTypeList>

<ic:PrivacyNotice>

http://www.samplesite.com/PrivacyPolicy.txt

</ic:PrivacyNotice>

</ic:InformationCard>

</dsig:Object>

</dsig:Signature>

Postoje dva tipa kartica: osobne i upravljačke. Osobne kartice korisnik stvara unutar Windows CardSpace-a. Takve kartice izdane su od lokalnog Windows CardSpace izdavatelja identiteta. Za razliku od osobnih, upravljačke kartice izdane su od drugog izdavatelja identiteta i moraju biti eksplicitno uključene u Windows CardSpace.

Interakcija između subjekta, pouzdajuće strane, kartice, pripadajućeg izdavatelja identiteta i Windows CardSpace-a prikazana je na slici 4.1.

Slika 4.1 Interakcija u sustavu Windows CardSpace

Prilikom zahtijevanja sigurnosne značke Web stranica ili servis (pouzdajuća strana) specificira polja koja su potrebna za autentifikaciju. Klijentska aplikacija (Web preglednik) poziva Windows CardSpace (1) predajući mu te podatke. Windows CardSpace pomoću tih podataka prezentira korisniku samo kartice koje ispunjavaju postavljene zahtjeve unutar tih podataka (2). Kad korisnik odabere katicu (3), Windows CardSpace autentificira korisnika korištenjem metode definirane od izdavatelja identiteta pozivajući odgovarajući izdavatelj identiteta referenciran unutar kartice (4) koji posjeduje sigurnosnu značku koja sadrži informacije zahtijevane od pouzdajuće strane (5). Izdavatelj identiteta šalje potpisanu i kriptiranu sigurnosnu značku klijentskoj aplikaciji (6) koja istu prosljeđuje pouzdajućoj strani (7).

Kartice su spremljene i osigurane na lokalnom računalu u datoteci koja je dvostruko kriptirana, zaštićena ključem računala, korisničkog Windows login-a te opcionalno pinom. Za kriptiranje privatnih podataka i generiranje ključeva za kriptiranje koriste se uniformni identifikator (engl. „Uniform Identifier“) i glavni ključ (engl. „Master key“). Za više detalja o osiguravanju kartica na lokalnom računalu pogledati referencu [7] u popisu literature.

Ukoliko korisnik koristi više od jednog računala kartica može biti eksportirana u obliku kriptirane datoteke i zatim uključena na drugo računalo.

4.2 Osobne kartice

Osobne kartice stvaraju se kroz Windows CardSpace unutar „Control Panela“. Prilikom stvaranja osobne kartice stvaraju se dvije stvari:

1. skup polja koja sadržavaju neke osobne informacije,

2. karticu koja sadrži popis polja na koja se ona odnosi.

Lokalni izdavatelj identiteta izdaje osobne kartice koje predstavljaju niz polja i sigurno pohranjene podatke vezane uz ta polja. Sigurno pohranjeni podaci se na zahtjev prenose unutar sigurnosne značke. Slika 4.2 ilustrira na koji način osobne kartice ukazuju Windows CardSpace izdavatelju identiteta koja je polja potrebno pohraniti unutar zahtijevane sigurnosne značke.

Slika 4.2 Generiranje sigurnosne značke iz osobnih kartica

Prilikom stvaranja osobne kartice korisnik može unijeti samo unaprijed definirana polja, informacije tipa ime, prezime, adresu elektroničke pošte i sl.

Polja su predstavljena usklađenim identifikatorima resursa (engl. „Uniform Resource Identifier“ - URI) iz „WS-Identity“ namespace-a „schemas.xmlsoap.org/ws/2005/05/identity“. Ovo su sva polja predstavljena usklađenim identifikatorima resursa:

http://schemas.xmlsoap.org/.../identity/claims/privatepersonalidentifier

http://schemas.xmlsoap.org/.../identity/claims/name

http://schemas.xmlsoap.org/.../identity/claims/givenname

http://schemas.xmlsoap.org/.../identity/claims/surname

http://schemas.xmlsoap.org/.../identity/claims/emailaddress

http://schemas.xmlsoap.org/.../identity/claims/streetaddress

http://schemas.xmlsoap.org/.../identity/claims/locality

http://schemas.xmlsoap.org/.../identity/claims/stateorprovince

http://schemas.xmlsoap.org/.../identity/claims/postalcode

http://schemas.xmlsoap.org/.../identity/claims/country

http://schemas.xmlsoap.org/.../identity/claims/homephone

http://schemas.xmlsoap.org/.../identity/claims/otherphone

http://schemas.xmlsoap.org/.../identity/claims/mobilephone

http://schemas.xmlsoap.org/.../identity/claims/dateofbirth

http://schemas.xmlsoap.org/.../identity/claims/gender

http://schemas.xmlsoap.org/.../identity/claims/webpage

Stvaranje osobne kartice ne razlikuje se mnogo od stvaranja korisničkog imena i lozinke za neku Web stranicu. Web stranica ili Web servis može povezati osobnu karticu s korisničkim računom tako da korisnik može u samo nekoliko pritisaka mišem pomoću Windows CardSpace-a biti autentificiran umjesto da upisuje korisničko ime i pripadajuću lozinku. Jedinstveni identifikator zasnovan na osobnom privatnom identifikatoru (engl. „Personal Private Identifier“ - PPID) koristi se za povezivanje korisničkog računa sa osobnom karticom. Osobni privatni identifikator jedinstven je za svaku kombinaciju kartice i pouzdajuće strane. U tom slučaju ukoliko se ista kartica koristi kod više pouzdajućih strana svaka će imat jedinstveni osobni privatni identifikator. Time je zaštićena privatnost korisnika.

4.3 Upravljačke kartice

Za razliku od osobnih upravljačke kartice mogu predstavljati bilo koja polja koja izdavatelj identiteta podržava. U ovom slučaju podaci su pohranjeni na sustavu izdavatelja identiteta, a ne na lokalnom računalu. Upravljačke kartice ne mogu biti stvorene unutar Windows CardSpace-a jer lokalni pružatelj identiteta ne može izdati kartice sa proizvoljnim poljima. Izdavatelj identiteta može izdati upravljačke kartice koje predstavljaju polja za koja on može generirati sigurnosne značke. Kako izdavatelj identiteta mora biti upoznat s poljima koja pouzdajuća strana zahtjeva oni moraju biti povezani, nerijetko u vlasništvu iste kompanije.

Primjerice ukoliko korisnik ima račun u banci izdavatelj identiteta može korisniku izdati upravljačku karticu koja predstavlja sigurnosnu značku koja može biti izdana od tog izdavatelja identiteta. Kako bi se spriječio rizik povezan s korištenjem korisničkog imena i lozinke upravljačka kartica može biti instalirana unutar Windows CardSpace-a koju korisnik može koristiti za autentifikaciju na stranice te banke. Banka prilikom izdavanja upravljačke kartice mora korisnički račun povezat s računom u banci.

Kad korisnik odabere karticu kako bi se autentificirao kod bankovne pouzdajuće strane, samo odgovarajuće upravljačke kartice koje predstavljaju zahtijevana polja, mogu biti odabrane. Upravljačke kartice ne sadržavaju vrijednosti već samo nazive polja koja predstavljaju. Podaci se preko Windows CardSpace-a dohvaćaju od izdavatelja identiteta unutar kriptiranih sigurnosnih značaka. Slika 4.3 ilustrira na koji način upravljačke kartice ukazuju bankovnom izdavatelju identiteta koja polja je potrebno pohraniti unutar sigurnosne značke.

Slika 4.3 Generiranje sigurnosne značke pomoću upravljačkih kartica

Svaka povezana pouzdajuća strana izdavatelj identiteta moraju se složiti oko polja koja će biti uključena unutar sigurnosnih značaka. Ta polja mora biti moguće identificirati pomoću jedinstvenog usklađenog identifikatora resursa.

Iako su upravljačke kartice osigurane unutar lokalnog računala i mogu biti eksportirane na druga računala, aktualna polja su spremljena kod izdavatelja identiteta i ne napuštaju ga bez da prethodno nisu pohranjena unutar kriptirane sigurnosne značke. Izdavatelj identiteta kriptira sigurnosnu značku javnim ključem pouzdajuće strane tako da nitko, niti čak Windows CardSpace ne može vidjeti podatke unutar značke. Ukoliko pak korisnik želi vidjeti podatke koji se šalju pouzdajućoj strani, posebna značka može biti zatražena od izdavatelja identiteta. Ta značka kriptirana je tako da je Windows CardSpace može dekriptirati i vidjeti podatke koji se u njoj nalaze.

4.4 Preglednici i selektori identiteta

Postoje i drugi selektori identiteta koji pružaju istu funkcionalnost kao i Windows CardSpace unutar Windows-a. Windows CardSpace ili bilo koji drugi selektor identiteta može biti korišten za odabir osobne ili upravljačke kartice kako bi zadovoljio zahtjeve autentifikacije.

Kako bi Web aplikacije podržale autentifikaciju osobnim ili upravljačkim karticama moraju imati Web stranicu koja sadržava objekt oznake ili HTML binarni postupak koji opisuje informacije koje ta stranica zahtjeva. Preglednici koji podržavaju te oznake i imaju instaliran dodatak za informacijske kartice u mogućnosti su pokrenuti odgovarajući selektor identiteta preko kojeg će korisniku biti omogućen odabir kartice. Ne postoji poseban sloj između Windows CardSpace-a kao selektora identiteta, Internet Explorera kao Web preglednika i ASP.NET-a kao Web site tehnologije. Ostali Web preglednici imaju svoje specifične dodatke koji im omogućavaju takvo ponašanje. Isto tako svaki operacijski sustav ima svoj vlastiti selektor identiteta koji podržava informacijske kartice.

Bilo koja Web platforma, uključujući ASP.NET može pružiti stranice koje uključuju zahtijevanu objekt oznaku ili XHTML binarni postupak kako bi pokrenula selektor identiteta. Objekt oznaka koristi MIME tip „application/x-informationCard“ :

type="application/x-informationCard">

...

</object>

XHTML binarni postupak specificira se unutar XHTML-a korištenjem „#default#informationCard“ unutar <informationCard> elementa:

<ic:informationCard name="xmlToken"

style="behavior:url(#default#informationCard)" ...="" >

...

</ic:informationCard>

Unutar elemenata <object> i <informationCard> specificiraju se parametri koji opisuju polja koja Web stranica zahtjeva za autentifikaciju informacijskim karticama.

Iako ranije verzije Internet Explorera podržavaju jedino objekt oznake i XHTML, s verzijom Internet Explorera 7.0 podržane su informacijske kartice korištenjem MIME rukovatelja, dodatkom pod nazivom „Microsoft Information Card IE Helper“ dostupnim u icardie.dll-u. Sljedeći ključ registra povezuje MIME tip za informacijske kartice sa rukovateljem:

HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-informationCard

Ovaj MIME rukovatelj povezan je tada sa objekt oznakom i konfiguracijskim postavkama preglednika. Taj rukovatelj odgovoran je za pozivanje selektora identiteta predajući mu parametre specificirane unutar objekt oznake ili XHTML binarnog postupka. Windows CardSpace za osnovni selektor identiteta unutar Internet Explorer-a 7.0 postavlja sljedeći ključ registra:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\InformationCard Token Provider

Za sintaksu koja koristi objekt oznaka MIME rukovatelj poziva se preko „InformationCardSigninHelper“ klase, omogućen po uobičajenim postavkama unutar popisa korištenih dodataka Internet Explorera 7.0. prikazanog na slici 4.4.

$mhtml:file://C:\Users\Ivan\Desktop\Diplomski%2011_07\CardSpace%20columns\Identity%20Secure%20Your%20ASP_NET%20Apps%20And%20WCF%20Services%20With%20Windows%20CardSpace.mht!http://i.msdn.microsoft.com/cc163434.fig08.gif$

Slika 4.4 MIME rukovatelj informacijskim karticama unutar Internet Explorer-a 7.0

Za provjeru podržanosti informacijskih kartica na različitim Web preglednicima može se za početak koristiti provjera „UserAgent“-a u potrazi za Internet Explorer 7.0 i podrškom za „.NET common language runtime“-om verzijom 3.0. Ovako izgleda string vrijednost „UserAgent“-a koja označava podržavanje informacijskih kartica:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;

.NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)

Unutar ASP.NET-a provjera se može izvesti korištenjem „UserAgent“ svojstva „Request“ objekta na sljedeći način:

string userAgent = Request.UserAgent;

if (userAgent.Contains("MSIE 7.0") && userAgent.Contains(".NET CLR 3.0"))

{

Response.Write("Information cards are supported, but might not be enabled.");

}

else

{

Response.Write("Information cards may not be supported.");

}

Ovakav način provjere ima neke nedostatke. Naime unutar ostalih Web preglednika (osim Internet Explorera) koji mogu podržavati Windows CardSpace, MIME rukovatelj može biti onemogućen. Bolje rješenje je korištenje klijentskog skriptnog izvornog teksta programa koji detektira podržavanje Windows CardSpace-a čak i kad je rukovatelj onemogućen.

Internet Explorer 7.0 i odgovarajuće MIME rukovateljeve postavke odgovorne su za pokretanje Windows CardSpace-a iz objekt oznake i XHTML binarnog postupka. Osim toga Web stranica mora koristiti SSL sigurnu komunikaciju. Certifikati sa dodatnom provjerom izdani od strane pouzdanog korijenskog službe ovjeravanja (engl. „Certification Authority„ - CA) kao što su „VeriSign“ ili „Thawte“, neće zahtijevati nikakve specijalne postavke, ali ukoliko se koriste testni certifikati, potrebno je instalirati testne SSL certifikate kao pouzdane korijenske certifikate i dodati Web stranicu u listu pouzdanih Web stranica unutar Internet Explorera 7.0.

4.5 Objekt oznaka i parametri XHTML binarnog postupka

Kao što je prije spomenuto za pokretanje selektora identiteta unutar podržanog Web preglednika mogu se koristiti objekt oznake ili XHTML binarni postupak. Unutar bilo kojeg od njih potrebno je postaviti osnovni skup svojstava unutar dodataka za informacijske kartice Web preglednika. Na slici 4.5 vidi se popis svojstava informacijskih kartica i njihovo objašnjenje.

Svojstvo	Opis
requiredClaims (obavezno)	Mogu se navesti bilo koja svojstva osobnih kartica navedena unutar liste polja predstavljena URI-ovima iz „WS-Identity“ namespace-a ili navesti polja upravljačkih kartica. Ukoliko polje ne može biti dohvaćeno iz osobnih kartica potrebno je instalirati odgovarajuću upravljaču karticu.
issuer (opcionalno)	Označava kojem izdavatelju identiteta je potrebno poslati zahtjev za sigurnosnom značkom. Unutar osnovnih postavki stoji URI za osobne značke: „schemas.xmlsoap.org/ws/2005/05/identity/issuer/self“. Potrebno je ostaviti ovu opciju kako bi se pokrenuo Windows CardSpace.
issuerPolicy (opcionalno)	Označava URL na kojem se može naći sigurnosna politika za izdavatelj identiteta. Vrijednost ne mora biti postavljena ukoliko se radi o lokalnom izdavatelju identiteta.
tokenType (opcionalno)	Ukoliko je izostavljeno unutar osnovnih postavaka stoji URI za SAML 1.0 značke „urn:oasis:names:tc:SAML:1.0:assertion“. Za osobne kartice može se postaviti ili SAML 1.0 ili SAML 1.1 format značke: „http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1“. Sve ostalo ukazuje na upravljačke kartice.
optionalClaims (opcionalno)	Za neka od polja osobnih ili upravljačkih kartica može se postaviti da su opcionalna. To omogućava Windows CardSpace-u da korisniku pruži mogućnost odabira koje opcionalne informacije želi poslati unutar sigurnosne značke.
privacyVersion (opcionalno)	Specificira verziju sigurnosne politike privatnosti. Ukoliko se verzija promijeni korisnik će biti obaviješten o tome i dobit će priliku pregledati sve promjene unutar sigurnosne politike privatnosti.

Slika 4.5 Svojstva informacijskih kartica

Kod korištenja objekt oznake svojstva se mogu postaviti na sljedeći način:

type="application/x-informationCard" >

<param name="issuer"

value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"/>

<param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/

2005/05/identity/claims/privatepersonalidentifier

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>

<param name="optionalClaims" value="http://schemas.xmlsoap.org/ws/

2005/05/identity/claims/dateofbirth"/>

</object>

Svaki <param> parametar preko imena reprezentira jedno od svojstava informacijskih kartica. Vrijednosti parametara „requiredClaims“ i „optionalClaims“ navedene su u listi polja URI-ova razdvojeni prazninama. Opcionalno parametri „issuer“ i „tokenType“ mogu biti izostavljeni te će se u tom slučaju koristiti unaprijed postavljene vrijednosti.

Kod korištenja XHTML binarnog postupka svojstva informacijskih kartica mogu se postaviti na sljedeći način:

<ic:informationCard name="informationCards"

style="behavior:url(#default#informationCard)"

issuer="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"

tokenType="http://docs.oasis-open.org/wss/

oasis-wss-saml-token-profile-1.1#SAMLV1.1">

<ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05/

identity/claims/privatepersonalidentifier" optional="false" />

<ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05/

identity/claims/emailaddress" optional="false" />

<ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05/

identity/claims/dateofbirth" optional="true" />

</ic:informationCard>

U ovom slučaju koriste se atributi: „style“, „issuer“ i „tokenType“ za specificiranje željenog ponašanja. Svako polje definirano je unutar <add> podoznake označavajući URI polje i njegovu opcionalnost. Najmanje jedno polje mora biti specificirano.

U oba slučaja pritiskom na „Submit“ gumb Web preglednik poziva MIME rukovatelja predajući mu parametre za selektor identiteta. Nakon što se odabere odgovarajuća kartica, potpisana i kriptirana značka šalje se stranici u obliku parametrizirane forme za <object> ili <informationCard> identifikator.

Ukoliko su iz nekog razloga informacijske kartice onemogućene unutar preglednika ili nije ostvarena SSL sigurna komunikacija parametrizirana forma neće sadržavati <informationCard> identifikator. Ukoliko se pak Windows CardSpace pokrene i korisnik otkaže odabir kartice iz nekog razloga, parametrizirana forma sadržavati će <informationCard> identifikator sa praznim stringom. Web stranica ne može ništa učiniti sve dok <informationCard> parametrizirana forma ne sadrži <encryptedData> element.

Bez obzira koja sintaksa se koristila Windows CardSpace može biti pokrenut unutar ASP.NET stranice na zahtjev, ali pritom je potrebno razmotriti nekoliko dodatnih koraka kako bi se osiguralo da se Windows CardSpace poziva samo za specifični „Submit“ gumb. ASP.NET stranice imaju samo jedan aktivni <form> objekt te ukoliko se <object> ili <informationCard> oznaka nalazi samo unutar <form> objekta, svaki gumb koji uzrokuje „post back“ na poslužitelj pokrenut će Windows CardSpace.

Kako bi se izbjeglo ovakvo ponašanje <object> ili <informationCard> oznaka može se postaviti unutar rubrike HTML zaglavlja i eksplicitno pozvati korištenjem skripte pritiskom na određeni gumb. U sljedećem dijelu HTML-a vidljiv je primjer jednostavne ASP.NET stranice koja uključuje <object> oznaka unutar zaglavlja zajedno sa „SelectInformationCard“ funkcijom koja aktivira objekt i postavlja vraćenu vrijednost unutar skrivenog ulaznog polja. Unutar <form> oznake nalazi se ASP.NET „Login“ kontrola i gumb „ImageButton“.

<html>

<title>Login</title>

type="application/x-informationCard" > ... </object>

function SelectInformationCard()

{

var infoCardObject =document.getElementById("informationCards");

var hiddenToken = document.getElementById("hiddenXmlToken");

hiddenToken.value = infoCardObject.value;

}

</script>

</head>

<body>

<form id="standardLogin" name="standardLogin" method="post"

runat="server">

<asp:Login ID="Login1" runat="server" />

<asp:ImageButton ID="cardSpaceSubmit" runat="server"

ImageUrl="cardspacelogin.jpg"

OnClientClick="SelectInformationCard()"

OnClick="CardSpaceLogin" />

<input id="hiddenXmlToken" type="hidden" name="hiddenXmlToken"

value="empty"/>

</form>

</body>

</html>

Nakon što se pritisne na „submit“ kontrole za prijavu, Windows CardSpace se ne poziva jer se nalazi unutar objekt oznake u zaglavlju rubrike. Suprotno tome, pritiskom na „ImageButton“ poziva se zbog postavljene vrijednosti naziva funkcije „SelectInformationCard“ postavljenog unutar „OnClientClick“ atributa. Bitno je zamijetiti da na je ovaj način moguće kontroliranje pokretanja Windows CardSpace-a.

4.6 Obrada sigurnosnih značaka

Nakon poziva Windows CardSpace-a potpisana i kriptirana sigurnosna značka je poslana. U slučaju prethodnog primjera HTML koda „hiddenXmlToken“ ulazno polje sadržava rubriku <encryptedData> ukoliko je značka uspješno izdana. Ukoliko se Windows CardSpace uspješno pokrene, ali korisnik prekine odabir kartice, „hiddenXmlToken“ ulazno polje sadržavat će vrijednost stringa „empty“ što je njegova inicijalna vrijednost. Prvi problem kod kojeg se nailazi kod obrade kriptirane značke unutar Web stranice je ta što ASP.NET zabranjuje slanje XML i HTML podataka kako bi se reducirala ranjivost i napadi skriptama. Na stranici će se pojaviti „HttpRequestValidationException“ iznimka koja izgleda sljedeće:

System.Web.HttpRequestValidationException: A potentially dangerous

Request.Form value was detected from the client

(informationCards="<enc:EncryptedData T...").

Ova provjera može se onemogućiti za sve Web stranice tako da se postavi vrijednost unutar <system.web> rubrike „web.config“ datoteke u „false“: <pages validateRequest="false"/>.

Puno bolje riješenje je da se za stranicu koja sadrži <object> ili <informationCard> oznaka postavi vrijednost ValidateRequest="false" unutar „@Page“ direktive. Ukoliko se radi o C# kodu zaglavlje „Login.aspx“ stranice tada bi izgledalo ovako:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="Login"

ValidateRequest="false" %>

Za dohvaćanje vrijednosti polja unutar ASP.NET aplikacije koristi se „TokenProcessor“ klasa. Kreira se „Token“ objekt i preko svojstva „Claims“ dohvaćaju se vrijednosti polja. Sljedeći primjer pokazuje kako to izgleda u C# kodu za primjer od maloprije:

string token = Request.Form["hiddenXmlToken"] as string;

if (!String.IsNullOrEmpty(token))

{

Token tokenProcessor = new Token(token);

string ppid = tokenProcessor.Claims[ClaimTypes.PPID];

string emailaddress = tokenProcessor.Claims[ClaimTypes.Email];

string dateofbirth = tokenProcessor.Claims[ClaimTypes.DateOfBirth];

}

Sigurnosna značka kriptirana je korištenjem SSL certifikata Web stranice. Token klasa koristi „thumbprint“ certifikata za pronalazak odgovarajućeg privatnog ključa. ASPNET ili NETWORK SERVICE identitetu moraju biti postavljena prava pristupa privatnom ključu kako bi dekriptiranje bilo uspješno. Dekriptirani rezultati se zatim konvertiraju u „SamlToken“ i provjeravaju kako bi se osigurala njihova ispravnost, odnosno detektiralo ukoliko je netko izmijenio prenesene podatke. Nakon validacije vrijednosti polja ista su dostupna za korištenje.

Za slučaj osobnih kartica ključ koji se koristi za potpisivanje značaka nije poznat Web aplikaciji jer se kreira u zadnji tren ovisno o tome koja stranica ga zahtjeva. Ključ se kreira za značku samo prvog puta kad stranica zatraži tu značku. Zbog toga jedini način povezivanje kartice s računom je preko sažetka osobnog privatnog identifikatora.

Kod upravljačkih kartica budući da postoji veza između pouzdajuće strane i izdavatelja identiteta potrebno je dodati dodatni korak unutar obrade značke kako bi se provjerilo je li značka potpisana od izdavatelja identiteta kojem pouzdajuća strana vjeruje. Ovo može biti izvedeno korištenjem javnog ključa izdavatelja identiteta za provjeru potpisa.

4.7 Povezivanje kartice s korisničkim računom

Nakon što je objašnjeno na koji način se pokreće Windows CardSpace iz ASP.NET-a te na koji način se obrađuju podaci unutar sigurnosne značke potrebno je objasniti što se može učiniti s njima. Na to utječe podatak dali se radi o osobnoj ili o upravljačkoj kartici.

Web stranice koje podržavaju osobne kartice na ovaj način povećavaju sigurnost i kvalitetu autentifikacije korisnika. Polja unutar sigurnosne značke ne izbacuju potrebu korištenja autorizacije zasnovane na ulogama. Način na koji se podaci unutar tih polja mogu iskoristit je tako da se osobna kartica poveže sa postojećim korisničkim računom. Nakon toga korisnik može koristiti kartice za autentifikaciju na tim stranicama.

Slika 4.6 ilustrira interakciju između korisnika, Web stranice i Windows CardSpace-a za postizanje cilja. Korisnik može unaprijed stvoriti osobnu karticu i zatim se prijaviti na stranicu kako bi povezao stvorenu osobnu karticu sa postojećim korisničkim računom. Karticu je također moguće stvoriti tijekom odabira kartice unutar selektora identiteta ukoliko ne posjeduje niti jednu karticu koja zadovoljava svojstva Web stranice na kojoj se povezivanje računa želi napraviti. Nakon što se odabere osobna kartica sigurnosna značka šalje se Web stranici na procesiranje. Polja sadržana unutar sigurnosne značke moraju biti dovoljna za prepoznavanje korisničkog računa nakon što se korisnik sljedeći put prijavi na stranicama.

Slika 4.6 Povezivanje osobnih kartica s korisničkim računom Web stranica

Sljedeći isječak izvornog teksta programa povezuje karticu sa postojećim korisničkim računom ukoliko se adresa elektroničke pošte korisničkog računa prijavljenog korisnika podudara sa adresom unutar polja adrese elektroničke pošte unutar sigurnosne značke:

MembershipUser user = Membership.GetUser(this.User.Identity.Name);

if (user.Email == emailaddressClaim)

{

user.Comment = ppidClaim;

Membership.UpdateUser(user);

}

Unutar izvornog teksta programa koristi se polje za komentare za spremanje osobnog identifikacijskog identifikatora. Kako je to polje jedinstveno za karticu i pouzdajuću stranu kojoj je kartica poslana, ono jedinstveno autentificira korisnika.

Nakon što se korisnik svaki sljedeći put prijavi korištenjem osobne kartice, polje adrese elektroničke pošte može biti iskorišteno za pronalaženje korisničkog računa korištenjem ASP.NET „Membership“ API-ja. Podudaranje osobnog identifikacijskog identifikatora u pronađenom korisničkom računu s onim u polju sigurnosne značke označava da se radi o ispravnom korisniku. Primjer izvornog teksta programa koji to provjerava izgleda ovako:

MembershipUserCollection matchingUsers =

Membership.FindUsersByEmail(emailaddressClaim);

if (matchingUsers.Count > 0)

{

foreach (MembershipUser user in matchingUsers)

{

if (user.Comment == ppid)

{

authenticatedUser = user;

break;

}

Nakon što se uspješno pronađe korisnički račun koristi se uobičajeni korak stvaranja autentifikacijske kartice. Poziv metode „RedirectFromLoginPage“ to omogućava. Izvorni tekst programa koji poziva tu metodu izgleda ovako:

FormsAuthentication.RedirectFromLoginPage(

authenticatedUser.UserName, true);

Zanimljivo je primijetiti da se na isti način autentificira korisnik koji nije koristio Windows CardSpace za autentifikaciju što znači da se može koristiti tradicionalna autorizacija zasnovana na korisničkom imenu i lozinci.

Povezivanje korisničkog računa kod upravljačkih kartica nešto se razlikuje od povezivanja kod osobnih kartica. Distribuiranje upravljačkih kartica krajnjim korisnicima može biti ostvareno na nekoliko načina. Jedan od njih je taj da se korisniku dozvoli zatraživanje kartice nakon uspješne prijave na stranicu. Kartica se nakon toga uključuje unutar Windows CardSpace-a za kasniju uporabu prilikom prijave na tu istu stranicu.

Slika 4.7 ilustrira tijek te komunikacije. Kako upravljačke kartice mogu sadržavati bilo koji skup polja valjan izdavatelju identiteta i pouzdajućoj strani ona mogu imat puno više značenja u procesu autorizacije. Skup polja primljen unutar sigurnosne značke pouzdajućoj strani može indicirati listu prava nad aplikacijom. U tom slučaju ASP.NET članstva i uloge mogu biti zaobiđene.

Slika 4.7 Zahtijevanje i uključivanje upravljačkih kartica

5 Praktični rad

Kao što je spomenuto u dokumentu, unutar sustava koji omogućava autentifikaciju pomoću CardSpace-a postoje tri uloge:

Korisnik (subjekt) - Entitet povezan s digitalnim identitetom. Digitalni identitet ne mora nužno biti povezan samo s ljudima. Identitet može predstavljati organizacije, programe, računala i dr. ;

Izdavatelj identiteta (eng. „Identity Provider“) - Izdavatelj identiteta je upravo ono što samo ime sugerira. On pruža digitalni identitet za korisnika. Digitalni identitet izdan od strane različitih izdavatelja identiteta različitih pružatelja usluga može nositi različite informacije i pružati različite razine osiguranja točnosti korisnikovih podataka;

Pouzdajuća strana (engl. „Relying Party“) - Aplikacija koja se na neki način oslanja (pouzdaje) na digitalni identitet. Pouzdajuća strana često koristiti identitet za autentifikaciju korisnika.

Unutar praktičnog rada stvorena je pouzdajuća strana i izdavatelj identiteta koji izdaje značke za tu pouzdajuću stranu. Pouzdajuća strana i izdavatelj identiteta ostvareni su kao Web aplikacije. Pouzdajuća strana omogućavat će autentifikaciju korisnika pomoću korisničkog imena i lozinke te autentifikaciju pomoću CardSpace-a. Na njoj će također biti moguće stvaranje novog korisničkog računa na klasičan način ispunjavanjem obrasca i stvaranje pomoću CardSpace-a.

Postoje dva slučaja korištenja ovog sustava:

1. Ukoliko korisnik odluči stvoriti račun na klasičan način ili ukoliko korisnik već ima otvoren račun njemu se nudi mogućnost da uz taj račun veže osobnu karticu. Nakon što korisnik poveže svoj korisnički račun s osobnom karticom, za autentifikaciju više ne mora koristiti lozinku nego se može autentificirati pomoću osobne kartice koju je povezao sa svojim korisničkim računom.

2. Korisnik nema otvoren korisnički račun i želi ga stvoriti pomoću osobne kartice. U tom slučaju korisnik kod svog lokalnog izdavatelja identiteta treba stvoriti osobnu karticu. Nakon toga treba pripadajući sigurnosna značka poslati pouzdajućoj strani koja iz njega iščita osobni privatni identifikator. Korisnik pomoću osobnog privatnog identifikatora kod izdavatelja identiteta kreira upravljačku karticu pomoću koje pouzdajuća strana kreira korisnički račun. Nakon stvaranja računa korisnik se može autentificirati pomoću osobne kartice, ali i na klasičan način pomoću lozinke.

5.1 Pouzdajuća strana

Pouzdajuću stranu čini Web aplikacija koja omogućava autentifikaciju na klasičan način pomoću lozinke ili autentifikaciju pomoću CardSpace-a. Kao što je spomenuto, ukoliko korisnik ima već stvoren korisnički račun njemu se nudi mogućnost povezivanja korisničkog računa s osobnom karticom koju zatim može koristiti za daljnju autentifikaciju. Izgled sučelja prikazan je na slici 5.1. Za komunikaciju koristi se „https“ protokol.

Slika 5.1 Pouzdajuća strana

Na početnoj stranici moguća je prijava na klasičan način ili pomoću CardSpace-a. Osim toga moguće je stvaranje novog korisničkog računa. Nakon autentifikacije, korisnik ima mogućnost povezivanja računa s osobnom karticom. Više o tome rečeno je u nastavku dokumenta.

5.2 Izdavatelj identiteta

U našem slučaju to će biti Web stranica koja pripada istoj organizaciji kao i pouzdajuća strana. Treba napomenuti da u stvarnosti to ne mora biti slučaj. Izdavatelj identiteta može biti u vlasništvu neke druge organizacije s kojom pouzdajuća strana surađuje. Pouzdajuća strana i izdavatelj identiteta izvedene su kao dvije različite Web aplikacije i mogu se nalaziti na različitim poslužiteljima. Nakon što korisnik kod izdavatelja identiteta stvori upravljačku karticu pomoću iste može stvoriti korisnički račun kod pouzdajuće strane.

Ukoliko se želi povećati razina sigurnosti kod stvaranja upravljačke kartice korisnik može osobno otići kod izdavatelja identiteta i kod njih lokalno stvoriti upravljačku karticu.

Izdavatelj identiteta ostvaren je kao Web aplikacija koja izdaje upravljačke kartice. Sastoji se od Web servisa koji izdaje sigurnosne značke i Web sučelja preko kojeg se omogućava stvaranje upravljačkih kartica. Za komunikaciju se koristi „https“ protokol koji doprinosi sigurnosti. Nakon što se kreira upravljačka kartica ona se može skinuti na lokalno računalo i instalirati unutar Windows CardSpace-a. Izgled sučelja za stvaranje upravljačke kartice izdavatelja identiteta prikazan je na slici 5.2.

Slika 5.2 Stvaranje upravljačke kartice

Kao što je spomenuto, izdavatelj identiteta sastoji se i od Web servisa koji izdaje sigurnosne značke. Nakon što korisnik odabere unutar CardSpace-a upravljačku karticu, CardSpace od izdavatelja identiteta zatraži sigurnosnu značku. Kako bi CardSpace mogao dobiti sigurnosnu značku, unutar izdavatelja identiteta mora biti pokrenut Web servis. Web servis se pokreće preko izvršne datoteke kao konzolna aplikacija. Izgled sučelja pokrenutog Web servisa prikazan je na slici 5.3.

Slika 5.3 Web servis

Na sučelju servisa vidljive su tri URL adrese na kojima servis čeka zahtjev za sigurnosnom značkom. Unutar upravljačke kartice postoje zapisi o ovim adresama koje služe CardSpace-u za dohvat sigurnosne značke.

5.3 Autentifikacija pomoću CardSpace-a

Unutar ovog poglavlja prikazana je autentifikacija u sustavu za dva slučaja:

5.3.1 Korisnik ima korisnički račun koji želi povezati s osobnom karticom.

Pretpostavimo da korisnik još nema korisnički račun kako bi pokazali na koji način se može stvoriti račun na klasičan način, unosom podataka unutar obrasca za stvaranje računa. Na početnoj stranici pouzdajuće strane potrebno je pritisnuti na link „Kreiranje računa“ nakon kojeg se prikazuje stranica koja omogućava stvaranje korisničkog računa preko obrasca. Slika 5.4 prikazuje ispunjen obrazac za stvaranje korisničkog računa. Pritiskom na gumb stvara se korisnički račun. Nakon toga omogućena je prijava korisnika s upravo stvorenim korisničkim računom.

Slika 5.4 Stvaranje korisničkog računa

Nakon uspješne prijave, korisniku se nudi opcija povezivanja računa prikazana na slici 5.5.

Slika 5.5 Povezivanje računa

Pritiskom na „Povezivanje računa“ otvara se stranica koja prikazuje gumb za povezivanje računa s osobnom karticom. Pritiskom na njega otvara se CardSpace koji omogućava odabir osobne kartice. Ukoliko korisnik nema osobnu karticu može je stvoriti unutar istog sučelja za odabir kartica prikazanog na slici 5.6.

Slika 5.6 Sučelje za odabir kartice

Budući da unutar CardSpace-a ne postoji niti jedna kartica pritiskom na link „Add a card“ moguće je stvoriti osobnu karticu. Nakon toga potrebno je odabrati stvaranje osobne kartice nakon čega se pokazuje sučelje koje omogućava unos opcionalnih podataka i podataka koje pouzdajuća strana zahtjeva označenih crvenom zvjezdicom. Slika 5.7 prikazuje unesene podatke prilikom stvaranja nove osobne kartice.

Slika 5.7 Stvaranje osobne kartice

Nakon unosa podataka potrebno je pritisnuti na gumb za spremanje osobne kartice nakon čega se ista nudi u popisu kartica koje mogu biti poslane pouzdajućoj strani. Prilikom stvaranja kartice moguće je odabrati i sliku koja može pomoći pri odabiru između velikog broja kartica. Slika 5.8 prikazuje izgled sučelja nakon uspješno stvorene osobne kartice.

Slika 5.8 Odabir stvorene osobne kartice

Pritiskom na upravo stvorenu karticu i na gumb za slanje od lokalnog izdavatelja identiteta dohvaća se sigurnosna značka koja sadržava podatke unesene kod stvaranja kartice i šalje pouzdajućoj strani. Nakon što je kartica poslana korisnik se može pokušati ponovno autentificirati, ovog puta pomoću osobne kartice. Za autentifikaciju osobnom karticom potrebno je unutar stranice za prijavu odabrati „Login osobnom karticom“ nakon čega se otvara Windows CardSpace i nudi mogućnost odabira osobne kartice. Odabirom stvorene osobne kartice korisnik se autentificira na sustav.

5.3.2 Korisnik nema korisnički račun i želi ga stvoriti uz pomoć osobne kartice i upravljačke kartice izdane kod izdavatelja identiteta.

Pretpostavimo da korisnik nema korisnički račun i želi ga stvoriti uz pomoć osobne kartice. Unutar početne stranice pouzdajuće strane potrebno je pritisnuti na link za stvaranje korisničkog računa nakon čega se prikazuje stranica za stvaranje novog računa prikazana na slici 5.9.

Slika 5.9 Stvaranje računa pomoću osobne kartice

Odabirom opcije „Kreiraj račun pomoću osobne kartice“ otvara se sučelje CardSpace-a koje omogućava odabir postojeće osobne kartice ili stvaranje nove. Kako ne bi došlo do konflikta stvorit će se nova osobna kartica. Nakon unosa podataka sučelje izgleda kao na slici 5.10.

Slika 5.10 Stvaranje nove osobne kartice

Nakon pritiska na gumb za snimanje osobne kartice te odabirom iste i slanjem pouzdajućoj strani, korisnik dobiva od pouzdajuće strane privatni osobni identifikator, prikazan na slici 5.11, koji služi sa stvaranje upravljačke kartice kod izdavatelja identiteta.

Slika 5.11 Privatni osobni identifikator

Nakon unosa podataka kod izdavatelja identiteta potrebnih za stvaranje upravljačke kartice sučelje izgleda kao na slici 5.12.

Slika 5.12 Stvaranje upravljačke kartice

Pritiskom na gumb za stvaranje kartice otvara se dijalog za preuzimanje upravo stvorene upravljačke kartice koji je prikazan na slici 5.13.

Slika 5.13 Preuzimanje upravljačke kartice

Pritiskom na gumb „Open“ otvara se sučelje CardSpace-a, prikazano na slici 5.14, koje nudi podatke o izdavatelju kartice i mogućnost instaliranja iste.

Slika 5.14 Instalacija upravljačke kartice

Nakon instaliranja upravljačke kartice ista je vidljiva u sučelju CardSpace-a za odabir kartica. Upravljačku karticu potrebno je poslati pouzdajućoj strani pritiskom na gumb „Pošalji upravljačku karticu“. Pritiskom na gumb otvara se sučelje za odabir kartica koje omogućava slanje samo upravljačkih kartica. Nakon odabira upravljačke kartice i njenim slanjem na pouzdajućoj strani kreira se novi korisnički račun. Stvaranjem računa omogućena je autentifikacija korisnika osobnom karticom novostvorenog korisnika.

6 Zaključak

U okviru diplomskog rada prikazana je jednostavna implementacija sustava za Web autentifikaciju pod nazivom MS Windows CardSpace. Prilikom implementacije posebna pozornost posvećena je prikazu na koji način sustav može biti implementiran unutar gotovih Web aplikacija koje koriste klasičnu metodu autentifikacije korisničkim imenom i lozinkom. Također je prikazano na koji se način može ostvariti podrška pružanja dvostrukog oblika autentifikacije, klasično korisničkim imenom i lozinkom te korištenjem CardSpace-a.

Mogućnost napretka sustava je proširenje uloge izdavatelja identiteta. U okviru praktičnog rada uloga izdavatelja identiteta bila je izdavanje upravljačkih kartica koje omogućavaju stvaranje korisničkog računa koji omogućava klasičnu autentifikaciju korisničkim imenom i lozinkom. Međutim, njegova uloga može biti puno kompleksnija. Izdavatelj identiteta može izdavati sigurnosnu značku unutar koje je definirana uloga koju korisnik ima u sustavu. Nakon uspješne autentifikacije korisnika na sustav pomoću osobne kartice, korisnik bi dohvatio odgovarajuću sigurnosnu značku, povezanu s upravljačkom karticom te time dobio odgovarajuću ulogu u sustavu.

Ovaj sustav relativno je nov u svijetu sustava za Web autentifikaciju te još nije uspio zaživjeti i zamijeniti postojeće sustave. Razlog tome je ili slaba educiranost korisnika i vlasnika korporativnih Web stranica ili strah od novih tehnologija. Vrijeme će pokazati dali je ovo samo još jedan pokušaj uvođenja novog sustava Web autentifikacije ili je ovo sustav koji će zaživjeti i uvesti promjene u već dugo korišteni sustav autentifikacije korisničkim imenom i lozinkom koji očigledno ima brojne nedostatke.

7 Literatura

[1] MSDN: Microsoft Developer Network,

dostupno na Internet adresi - http://msdn.microsoft.com/en-us/default.aspx , 1.9.2008.

[2] Windows Vista: Help and How to,

dostupno na Internet adresi - http://windowshelp.microsoft.com/Windows/en-US/default.mspx , 1.9.2008.

[3] Uvod u Windows CardSpace,

dostupno na Internet adresi - http://research.microsoft.com/~mbj/papers/CardSpace_One-Pager.pdf , 1.9.2008.

[4] Microsoft .NET Framework 3.9 Community (NetFx3),

dostupno na Internet adresi - http://netfx3.com/content/WindowsCardspaceHome.aspx , 1.9.2008.

[5] ASP.NET Wiki: Security: Windows card space,

dostupno na Internet adresi - http://wiki.asp.net/page.aspx/105/windows-card-space , 1.9.2008.

[6] Microsoft pushes InfoCard for secure online,

dostupno na Internet adresi - http://seattlepi.nwsource.com/business/259391_infocard14.html , 1.9.2008.

[7] Decrypting Windows CardSpace,

dostupno na Internet adresi - http://www.passcape.com/recovering_windows_infocards.htm , 1.9.2008.

[8] Schneider, B., "Applied Cryptography Second Edition: protocols, algori thms, and source code in C", John Wi ley & Sons, Inc., 1996.

[9] Eastlake, D., Kaufman, C., "Domain Name System Security Extensions", RFC 2065, IETF, January 1997.

[10] Michael Howard and David LeBlanc – Writing secure code for Windows Vista

[11] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995.

[12] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.

[13] Ylonen, T., Kivinen, T.,, Saarinen, M., Rinne, T., Lehtinen, S., "SSH Protocol Architecture" Study Guide Alvaro Retana, Don Slice, Russ White, “Advanced IP Network Design” Cisco Press, 1999

[14] Martin Krist, “Standard for Auditing Computer Applications” Auerbach Inc, 1999