Projekt Liberty Alliance
V spletu je shranjenih vedno več naših podatkov, nad njimi je težko ohraniti nadzor, pomenijo pa tudi grožnjo varnosti. Microsoft je predstavil storitev Passport, ki blaži ta problem. Liberty je odgovor drugih velikih podjetij na to storitev.
Liberty je v osnovi specifikacija upravljanja povezanih identitet (Federated Identity Management). Uporabnikom želi olajšati internetno nakupovanje, spletnim trgovcem pa povečati ustvarjeni prihodek, ker je nakupovanje enostavnejše in varnejše. Sedanje stanje je zelo nerodno, ker imajo uporabniki mnogo parov omrežnih uporabniških imen in gesel, ki so med seboj nepovezani. Obenem imajo fizične in pravne osebe vedno več atributov v elektronski obliki. Iste atribute moramo večkrat posredovati različnim organizacijam, katerih storitve potrebujemo, in to vsaki posebej. Vse skupaj lahko postane zelo zapleteno in nepregledno, tako stanje pomeni za uporabnika tudi večjo ogroženost njegovih podatkov. Če kdo vdre v informacijski sistem ene od organizacij, pri kateri ima uporabnik račun, pridobi veliko več občutljivih informacij, kot bi jih pri vpeljani povezani identiteti (Federated Identity), ki jo omogočajo specifikacije projekta Liberty. Zelo koristen je tudi za državno upravo, saj je ta eden poglavitnih virov posameznikove "identitete"; pomislimo na rojstno matično knjigo, stalno prebivališče, vozniška dovoljenja, poročne liste, evidenco zaposlitve, davčne številke, knjigo umrlih itd. Vpogled v te dokumente je veliko enostavnejši, če so ustrezno povezani in je za državljana ali uslužbenca dovolj, da se prijavi oziroma overi le na enem mestu.
Microsoft je sam prvi ugotovil, da je v tej tržni niši velik ekonomski in informacijski potencial ter pomemben vzvod moči, zato je razvil storitev Passport. Projekt Liberty je neposreden odgovor podjetja Sun, združenega z drugimi tekmeci Microsofta (ne samo iz računalniških korporacij), na to storitev. Za končne uporabnike sta obe storitvi brezplačni, pri čemer pa pri Passportu hrani Microsoft vse podatke v svoji centralni bazi, pri Liberty pa ima vsaka od organizacij svojo, ki pa se lahko med seboj povezujejo na podlagi pogodb in uporabnikovih dovoljenj. Storitvi torej nista različni izvedbi povsem iste naloge, saj so pri Passportu vse občutljive informacije shranjene pri Microsoftu, pri Liberty pa gre za bolj porazdeljeno rešitev.
Konzorcij
V konzorciju projekta je že več kot 150 organizacij z vsega sveta in večina jih je med najpomembnejšimi v svojem poslu. Velik pomen se posveča varstvu podatkov in skladnosti z zakonodajo s tega področja, kjer je (še) ni, pa najboljšo poslovno prakso. Podatke o uporabniku, ki so shranjeni pri eni organizaciji, sme le-ta posredovati drugi(m) le z njegovim izrecnim dovoljenjem in le v obsegu, ki ga je dovolil. Pri zakonodaji o varstvu osebnih podatkov sta za nas zanimivi direktivi Evropske unije o: obdelavi osebnih podatkov in prostem posredovanju le-teh (Direktiva 95/46/EC) ter varovanju osebnih podatkov pri obdelavi na področju elektronskih komunikacij (Direktiva 2002/58/EC).
Podjetjem, ki izvedejo specifikacije projekta Liberty, se dodatno priporoča upoštevanje navodil poštenega poslovanja. Ta navodila temeljijo na načelih obvestil (notice), izbir (choice) in nadzora, dostopa, varnosti, kakovosti, relevantnosti, pravočasnosti in odgovornosti, kar naj zagotovijo za vsako od vlog, v kateri nastopajo. Organizacije lahko v okviru Liberty nastopajo v eni ali več od naslednjih vlog:
Zgled rabe v spletnih programih
Denimo, da spletišče letalske družbe uporablja Sunov Identity Server, spletišče hotelskega podjetja pa Phaos Identity Provider - oba sta izvedena v skladu s specifikacijami Liberty. Letalska družba vodi povezano skupino partnerjev, v kateri je tudi hotelsko podjetje. Uporabnik je oba že uporabljal in ima pri njiju svoja računa, ki se med seboj razlikujeta. Podjetji sta sklenili pogodbo, s katero se zavezujeta, da druga drugi priznavata overitev uporabnika - torej, če se overi pri eni, velja za overjenega tudi pri drugi. Uporabnik npr. nato prijavi na spletišče letalske družbe ter poda uporabniško ime in geslo in rezervira let. Zatem iz istega spletišča sledi povezavi na spletišče hotela, kjer se prijavi z imenom in geslom, kot ga ima na spletišču hotela. Spletno mesto hotela ve, da je prišel s spletnega mesta letalske družbe, in ga vpraša, ali bi želel povezati računa (program bi ju lahko povezal sam, vendar mora zaradi nadzora nad podatki in zasebnosti uporabnikovih podatkov, vsaj prvič dobiti potrdilo). Če se uporabnik strinja, spletišči povežeta uporabnikova računa z zakrito ročico, s katero ga prepoznata, in velja kot dodatno identifikacijsko sredstvo za uporabnika za ti dve spletni mesti. Ob naslednjih obiskih velja, da če se je prijavil na enem od spletišč, povezanih s pogodbo, lahko uporablja vse brez novega prijavljanja, ko pa se odjavi iz enega od njih, ga sistem odjavi iz vseh.
Slika 1: Povezava identitete na podlagi specifikacij Liberty
Slika 1 prikazuje povezanost identitete uporabnika med spletiščema letalske družbe in hotela, kar imenujemo povezana identiteta (federated identity). Uporabnik bi lahko v povezano identiteto vključil še banko (če ta sodi v isto skupino) z elektronsko listnico, v kateri hrani številko kreditne kartice, ter z njo plačeval v okviru povezanih omrežij ponudnikov storitev, ne da bi moral znova in znova vnašati svoje osebne podatke.
Zahteve
Splošne zahteve za izvedbo so najširša podpora za razne spletne brskalnike, operacijske sisteme, programske jezike in omrežne infrastrukture, funkcijske zahteve pa: povezanost identitete, ugotavljanje pristnosti (authentication), uporaba psevdonimov (use of pseudonyms), podpora anonimnosti (support for anonymity) in globalna odjava (global logout).
Povezanost identitete zahteva obveščanje uporabnikov pred vključitvijo in pred prekinitvijo povezanosti identitete, medsebojno obveščanje ponudnikov storitev in skrbnikov identitete ob prekinitvi povezanosti identitete. Skrbnik identitete mora obvestiti ustrezne ponudnike storitev, če uporabnik zapre svoj račun pri njem. Ponudnik storitev lahko zahteva anonimno, začasno uporabnikovo identiteto. Vsak skrbnik in ponudnik storitev mora uporabniku predstaviti seznam povezanih identitet.
Ugotavljanje pristnosti mora omogočati vse načine premikov med skrbniki identitete in ponudniki storitev, v katerih nastopa uporabnik. Pri premikanju sme prenašati samo najnujnejše z njim povezane informacije, tako da napadalec s prisluškovanjem pridobi minimum podatkov o uporabniku. Pri izmenjavi podatkov med entitetami je treba zagotoviti njihovo tajnost, integriteto in pristnost. Podpirati mora več različnih metod za potrditev pristnosti uporabnika in jih združiti v posamezne razrede. Ponudniki storitev morajo imeti možnost, da naložijo skrbniku identitete vnovično overitev uporabnika z uporabo metode iz istega ali drugega razreda. Skrbnik identitete mora tudi imeti možnost, da na zahtevo ponudnika storitev overi uporabnika pri drugem skrbniku identitete in prenese to informacijo ponudniku.
Krog zaupanja (Circle of Trust)
Enkratna prijava in druge značilnosti uporabe Liberty specifikacij so izvedljive le, če podjetja oziroma druge organizacije sklenejo krog zaupanja. Sprejeti morajo dogovore, s katerimi urejajo medsebojno (elektronsko) poslovanje.
Krogi zaupanja niso izum projekta Liberty, temveč obstajajo že zelo dolgo (in zelo uspešno). Zgled takega kroga zaupanja je med drugim slavna Lloydova ladijska zavarovalnica. Okrog leta 1688 je Edward Lloyd v Londonu odprl kavarno, v kateri so se radi shajali ladijski kapitani, lastniki ladij in trgovci. Pomorski promet je močno naraščal in posel je cvetel. Čeprav so bili donosi veliki, je bilo veliko tudi tveganje. Z ladjo in tovorom je lahko poleg kapitana "potonil" tudi lastnik ladje in še kak trgovec,
Zato so se pojavili zavarovalniški posredniki, ki so jim lastniki ladij oziroma tovora plačali zavarovanje, oni pa so nato s tistim denarjem obiskovali trgovca za trgovcem, dokler ni bila ladja polno zavarovana. Vsak trgovec je prejel ustrezen del premije, glede na odstotek tveganja, posrednik pa provizijo. V tistih časih so bile komunikacije in novice zelo nezanesljive, Lloydova kavarna pa si je pridobila sloves zanesljivega vira informacij o ladijskem prometu; to je omogočilo uspešnost zavarovalniškega poslovanja, zato ga je večina potekala kar tam. Na začetku se je poslovalo zelo neformalno, potem pa je 79 podpisnikov in posrednikov sklenilo ustrezne pogodbe, s katerimi so uredili medsebojne odnose in Lloyd je postala njihova lastnina.
Zgradba povezane identitete
Liberty je v osnovi sestavljen iz naslednjih delov: spletnega preusmerjanja (Web redirection), spletnih storitev (Web services) ter metapodatkov in shem (Metadata & Schemas).
Spletno preusmerjanje je izvedeno ali s preusmerjanjem, temelječim na http, ali s preusmerjanjem, temelječim na obrazcih (form POST). V vsakem primeru se med skrbniki identitet in ponudniki storitev ustvari kanal, ki temelji na uporabniškem agentu.
Postopek vzpostavitve kanala med ponudnikom storitev in skrbnikom identitete s preusmerjanjem HTTP poteka tako:
V nadaljevanju ponudnik storitev in skrbnik identitete lahko komunicirata neposredno, s pomočjo spletnih storitev.
Spletne storitve nastopajo v arhitekturi Liberty kot sredstvo neposrednega komuniciranja med ponudniki storitev in skrbniki identitete.
V okvir metapodatkov in shem sodijo razni podrazredi podatkov in njihovi formati, ki se prav tako kot spletne storitve prenašajo neposredno med ponudniki in skrbniki. Ti podrazredi informacij so:
Izvedba enkratne prijave in povezovanja identitete
Člani kroga zaupanja lahko namesto dejanskega naziva računa uporabnika uporabijo zakrito ročico ali celo več teh ročic, nujno pa je, da skrbnik identitete ustvari za vsakega ponudnika storitev, ki ima več spletnih mest, eno. Ker morajo člani poznati zakrite ročice, jih trajno hranijo v svojih imenikih uporabnikov. Pri tem je mogočih več scenarijev. Lahko imamo povezavo neposredno med ponudnikom storitev in skrbnikom identite, med skrbnikom identitete in več ponudniki storitev in med ponudnikom storitev in več skrbniki identitete. Ko je identiteta uporabnika enkrat povezana na ustreznih skrbnikih identitete in ponudnikih storitev, je mogoča enkratna prijava, ki omogoča uporabo storitev pri vseh povezanih ponudnikih.
Varnost
Programi, izdelani v skladu s specifikacijami Liberty, so prav tako ranljivi za napade kakor drugi. Če so v programu napake, če vhodni parametri niso dobro preverjeni, če napadalec pridobi ustrezna pooblastila, če je geslo enostavno itd., jih bo lahko napadalec zlorabil. Vendar bo zato, ker z vdorom v en program ne bo pridobil toliko informacij, škoda manjša. Z Liberty uspešno zmanjšamo problem kraje identitete. Kraja identitete je v ZDA najpogostejše kaznivo dejanje belih ovratnikov, število njihovih žrtev je že preseglo 10 milijonov. Pri tem je kraja pogosteje izvedena s prestrezanjem pošte in brskanjem po (papirnatih) smeteh kakor z vdori v podatkovne zbirke strank. Zelo pogosto je tudi tako imenovano internetno "ribarjenje", imenovano phishing (iz fishing). Ko nepridipravi pridobijo dovolj informacij, začnejo prenakazovati denar, odpirati račune, na njih izdajati (nepokrite) čeke...
Arhitektura projekta Liberty 2.0
Liberty uporablja in nadgrajuje znane ter splošno sprejete spletne standarde, kot so http, WAP, XML, SOAP, WSDL, XML Signature, XML Encryption, SSL/TLS, WS-Security in SAML. Na njihovi podlagi sta zgrajeni Liberty povezava identitete (ID-FF), ki smo jo predstavili v članku, ter Liberty spletne storitve z identiteto (Liberty Identity Web Services Framework (ID-WSF)). ID-WSF uporablja ID-FF za ogrodje, ki omogoča ustvarjanje, odkrivanje in uporabo storitev, povezanih z identiteto. Na podlagi ID-WSF je zgrajena specifikacija vmesnikov za Liberty storitve identitete (Liberty Identity Services Interfaces Specifications (ID-SIS)). ID-SIS omogoča storitve, kot so registracija, knjiga stikov, koledar, geolokacija, navzočnost.
Liberty pri tem pomaga s tem, da skoraj nikjer ne izdaja informacij, s katerimi bi bilo mogoče identificirati uporabnika (personally identifiable information), ker skoraj vse komunikacije, v katerih nastopa subjekt, potekajo s pomočjo zakrite ročice (opaque handle), iz katere ni mogoče sklepati, za katerega uporabnika gre, če pa le postane znana, jo je mogoče enostavno nadomestiti z novo. Mogoče je izbrati močna gesla, ker si je v idealnem primeru dovolj zapomniti eno samo. Tako pridobijo tudi podjetja, ponudniki storitev, ki v praksi tako in tako nosijo večino ekonomskega bremena kraje in zlorabe identitete njihovih uporabnikov.
Za osnovno varnost, kot je varnost kanala med uporabnikom, skrbniki identitete in ponudniki storitev, mora poskrbeti izvajalec. Liberty zahteva zaščito kanala s SSL 3.0 oziroma TLS 1.0, čeprav lahko uporabimo tudi druge njima enakovredne varnostne mehanizme (npr. IPSec). Ponudniki storitev morajo preveriti pristnost skrbnikov identitete z njihovim elektronskim potrdilom, medtem ko je preverjanje pristnosti ponudnikov storitev s strani skrbnikov identitete izbirno.
Poleg varnosti kanala je na splošno treba poskrbeti tudi za elektronski podpis in preveritev sporočil, ki jih izmenjujejo skrbniki identitete in ponudniki storitev ter nekaterih delov sporočil na splošno. S tem zagotovimo celovitost in znan izvor podatkov. Zato moramo uporabiti še en par ključev (poleg para za SSL 3.0/TLS 1.0).
Uporaba piškotkov
Uporaba piškotkov znotraj Liberty je omejena iz varnostnih razlogov. Navadno se, razen kadar je znotraj kroga zaupanja več skrbnikov identitete, uporabljajo le za vzdrževanja lokalnega stanja med uporabnikovim brskalnikom ter skrbnikom identitete in/ali ponudnikom storitev. Kadar pa imamo več skrbnikov identitete, bi bilo idealno, da bi, potem ko se uporabnik overi pri enem, vpisal svoje podatke v piškotek, ki bi ga lahko ponudniki storitev nato prebrali. To lahko za entitete, povezane v krog zaupanja, izvedemo tako, da zanje ustvarimo novo, skupno domeno. Vanjo nato skrbniki identitete vpišejo svoje piškotke, ne da bi jih izpostavili napadalcem. Takim piškotkom pravimo piškotki skupne domene (common domain cookies). Ti so lahko trajni ali začasni, vanje od uporabnikovih podatkov vpišemo samo seznam skrbnikov identitet, tako da tudi, če pride do njegovega razkritja, to ne ogrozi varnosti.
Protokoli Liberty ID-FF
Programi Liberty so izvedeni s protokoli, ki omogočajo upravljanje povezanih identitet (identity federation management), preverjanje pristnosti prek različnih domen (cross-domain authentication) in upravljanje sej (session management). Pri povezovanju identitete znotraj kroga zaupanja nastopajo predvsem naslednji trije "igralci": principali, skrbniki identitete in ponudniki storitev. Ko skrbnik identitete enkrat overi principala, lahko nato zanj jamči ponudnikom storitev znotraj kroga zaupanja. Če skrbnik identitete izdaja jamstvo za principala s trajnim imenom, govorimo o povezanosti identitete med ponudnikom storitev in skrbnikom identitete. Če povežemo specifikacije Liberty s SAML, je skrbnik identitete trditvena stran (asserting party) in overitveni organ (authentication authority), ponudnik storitev pa odvisna stran (relying party).
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:liberty:iff:2003-08"
xmlns="urn:liberty:iff:2003-08"
xmlns:xs="http://www.w3.org/2001/XMLS chema"
xmlns:ac="urn:liberty:ac:2003-08"
xmlns:md="urn:liberty:metadata:2003-08"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:xenc ="http://www.w3.org/2001/04/xmlenc#"
elementFormDefault="qualified"
attributeFormDefault="unqualified"/>
<xs:import
namespace="urn:oasis:names:tc:SAML:1.0:assertion"
schemaLocation="oasis-sstc-saml-schema-assertion-1.1.xsd"/>
<xs:import
namespace="urn:oasis:names:tc:SAML:1.0:protocol"
schemaLocation="oasis-sstc-saml-schema-protocol-1.1.xsd"/>
<xs:import
namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation="http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd"/>
<xs:import
namespace="urn:liberty:ac:2003-08"
schemaLocation ="liberty-authentication-context-v1.2.xsd"/>
<xs:import
namespace="urn:liberty:metadata:2003-08"
schemaLocation= "liberty-metadata-v1.0.xsd"/>
<xs:include
schemaLocation="liberty-idff-utility-v1.0.xsd"/>
Izvleček 1: Glava Liberty ID-FF sheme
Kot vidimo, vsebuje glava sheme za iff (identity federation framework - ogrodje za povezanost identitete) naslednje druge sheme: ac (authentication context - okolje overitve pristnosti), md (metadata - metapodatki), saml (security assertion markup language - označevalni jezik za varnostne trditve), samlp (security assertion markup language protocol - protokole označevalnega jezika za varnostne trditve) in xenc (XML encryption - šifriranje XML).
Skupine
Protokole Liberty ID-FF lahko razdelimo v naslednje skupine:
Protokol za enkratno prijavo (Single Sign-On) in povezave (Federation)
Ta protokol definira protokol za zahteve (request) in odgovore (response), ki se izvaja med ponudnikom storitve in enim ali več skrbniki identitete. Deluje v dveh korakih, pri čemer je prvi korak izbiren:
Protokol za registracijo imen (Name Registration)
S tem protokolom se prijavi alternativna zakrita ročica principala. Z zakrito ročico nato skrbnik identitete in ponudnik storitve v nadaljevanju med komunikacijo referencirata principala, termin, s katerim jo imenujeta, je <IDPProvidedNameIdentifier>. V nadaljevanju po povezavi identitete lahko ponudnik storitev prijavi drugo ročico pri skrbniku, termin zanjo je <SPProvidedNameIdentifier>, dokler pa je ne prijavi, uporabljata prvo. Tako skrbnik identitete kot ponudnik storitev lahko prijavita novo zakrito ročico kadarkoli po tem, ko je bila sklenjena povezanost identitete. Dejansko ime mora biti edinstveno med vsemi skrbniki identitete, pri katerih ima principal povezano identiteto in med vsemi drugimi zakritimi ročicami, ki jih je prijavil skrbnik na zahtevo ponudnika storitev. Za prijavo <SPProvidedNameIdentifier> ročice pri skrbniku identitete ponudnik storitev pošlje <RegisterNameIdentifierRequest> sporočilo. Isto sporočilo lahko pošlje tudi skrbnik identitete ponudniku storitev, če želi spremeniti njegov <IDPProvidedNameIdentifier>.
Protokol za obveščanje o prekinitvi povezave z drugim(i) ponudniki (Federation Termination Notification oziroma De-federation)
Ta protokol omogoča uporabniku, da prekine povezavo svoje identitete med ponudnikom storitev in skrbnikom identitete. V tem primeru ponudnik storitev pošlje <FederationTerminationNotification> sporočilo skrbniku identitete. S tem ga obvesti, da ne bo več sprejemal njegovih overitvenih potrdil za uporabnika. To sporočilo je enosmerno in asinhrono.
Protokol za enkratno odjavo (Single Logout)
S tem protokolom ponudniki drug drugega obvestijo o odjavi principala. Ko se uporabnik odjavi na enem od skrbnikov ali ponudnikov, protokol skoraj hkrati prekine vse seje, ki jih ima s posameznim skrbnikom identitete. Uporabi se, kadar se uporabnik odjavi s skrbnika identitete ali ponudnika storitev. Če se odjavi s ponudnika storitev, mora ta poslati <LogoutRequest> sporočilo skrbniku identitete. Ta mora nato to sporočilo poslati vsem ponudnikom storitev in skrbnikom identitete, ki jim je izdal overitvena potrdila za tega uporabnika.
Protokol za pridobivanje zakritih ročic (Name Identifier Mapping)
Ta protokol omogoča ponudniku storitev pridobitev zakritih ročic iz povezav identitet (Identity Federation), v katerih ne sodelujejo. Tako lahko ponudnik komunicira z drugimi ponudniki storitev v povezavi z uporabnikom, ne da bi bil z njimi v povezani identiteti. Po tem, ko je ponudnik storitev poslal <NameIdentifierMappingRequest> sporočilo skrbniku identitete, mora ta odgovoriti z <NameIdentifierMappingResponse> sporočilom.
Sklep
Liberty ID-FF lahko uporabniku pomaga olajšati težave s preštevilnimi raztresenimi omrežnimi računi in zagotovi večjo zaupnost in varnost njegovih podatkov. Je tudi velika priložnost za podjetja, ker se lahko povežejo s partnerji, ki dopolnjujejo njihove storitve, v kroge zaupanja in tako vsi skupaj in vsak posebej povečajo svojo konkurenčnost. Koristi prinaša tudi vladnim službam, ki lahko tako poenostavijo in pocenijo svoje delovanje, omogoča pa tudi povezave med vladnimi službami različnih držav (npr. znotraj EU).
Spletna stran projekta: