Objavljeno: 31.10.2005 15:53 | Avtor: Ivan Verdonik | Monitor Oktober 2005

SAML - Označevalni jezik za varnostne trditve

Številni z dvermi opremljeni ponudniki storitev omogočajo "enkratno prijavo" (SSI, Single Sign-In). S SAML (Security Assertion Markup Language) gremo lahko korak naprej in omogočimo "enkratno prijavo" (SSO, Single Sign-On) na več spletnih mest.

SAML temelji na ogrodju XML, ki omogoča izmenjavo varnostnih informacij med domenami. Informacije so v obliki varnostnih trditev (security assertions) o entitetah (osebe in računalniki) v okviru posameznih varnostnih domen.

Gre za zamisel, da lahko eno spletno mesto jamči za identiteto in atribute (elektronski naslov, številka kreditne kartice) uporabnika enemu ali več drugim spletnim mestom. Temelj elementa sta tako ponudnik storitev istovetnosti (IdP - Identity Provider) in ponudnik storitev (SP - Service Provider). Pri tem je kritično, da potrdila o identiteti in atributih uporabnikov niso dostopna nepooblaščenim, zato vse kritične podatke šifriramo in elektronsko podpišemo. Varnostne trditve same po sebi ne zagotavljajo varne overitve, pač pa so kodirani stavki o dogodkih, ki so se že zgodili, kot so npr. overitve.

SAML uporabljamo predvsem za naslednji storitvi: enkratno prijavo (SSO - Single Sign-On) in povezovanje uporabniških računov (account linking). Motivi za uporabo SAML so štirje:

Piškotki v brskalniku (cookies) so vezani na domeno in jih ni mogoče med njimi prenašati, zato jih ni mogoče uporabljati niti, če ima ista organizacija več domen.

Če imamo poseben program, ki omogoča SSO, smo vezani nanj (ker ni standarden).

Varnost spletnih storitev še vedno ni dodelana. SAML omogoča tajnost, overitev in integriteto spletnih storitev od začetka do konca (end-to-end).

Povezovanje uporabniških računov.

Sestavni deli SAML so:

Trditve (Assertion). To so izjave o entitetah (uporabnikih in računalnikih), ki jih zahtevajo ponudniki storitev, najdemo pa jih pri ponudnikih storitev istovetnosti.

Protokoli SAML. Z njimi določamo način prenosa trditev med ponudniki istovetnosti in storitev ter izbiro konkretnih trditev. Tako kot trditve so tudi protokoli definirani s shemo XML.

Vezave (Bindings). Določajo nizkonivojne komunikacije (npr. SOAP, HTTP), s katerimi so implementirani protokoli SAML.

Orisi (Profile). Gre za specifične kombinacije zgornjih treh sestavnih delov, ki ponujajo določene storitve (npr. SSO s spletnim brskalnikom).

SSO

SSO omogoča, da se nam po tem, ko smo se na enem spletnem mestu overili, ni treba overiti še na drugem, z njim povezanem. Pri tem predpostavljamo, da gre za obdelavo podatkov, ki jih nepooblaščeni lahko zlorabijo (npr. denarne transakcije), in morajo zato ostati tajne. Poleg tega je običajno, da do povezanega spletnega mesta v drugi domeni (in v lasti drugega podjetja) pridemo prek povezave (link) na spletnem mestu, v katerem smo se overili. Zato, da lahko na povezanih spletnih mestih izvajamo občutljive operacije brez vnovične overitve, morajo organizacije in lastniki skleniti ustrezne dogovore.

Pogosto naveden primer uporabe SSO je pogodba med letalsko družbo in podjetjem rent-a-car. Po tem, ko se overimo na spletni strani letalske družbe, izberemo let in vpišemo številko kreditne kartice (če je družba že nima v zbirki podatkov). Nato lahko sledimo povezavi na spletno stran podjetja rent-a-car in najamemo avtomobil, ne da bi se še enkrat overili in vpisali številko kreditne kartice. Tako uporabniku spletno poslovanje precej poenostavimo, ne da bi zmanjšali njegovo varnost.

Trditev SAML (Assertion)

Trditev SAML je temelj celotnega standarda. Vsebuje podatke o uporabnikovi overitvi in jamči, da se je določen uporabnik z določenim načinom overitve, ki morebiti ima določene atribute, v okviru določenega časovnega intervala dejansko overil pri določenem organu overitve (Authentication Authority). Zgled varnostne trditve je, da se je uporabnik Janez Novak, ki ima elektronski naslov janez.novak@siol.net, overil v tem sistemu z geslom.

Spodaj je definirana trditev SAML po standardu SAML 1.1 (niso navedene vse podrobnosti).

Temeljni element trditve je element <Assertion>. To je sestavljen element, ki je podlaga za vse trditve in vsebuje več atributov in podelementov:

MajorVersion - glavna različica.

MinorVersion - pomožna različica.

AssertionID - enolična in unikatna oznaka trditve.

Issuer - organ SAML (Authority), ki je ustvaril to trditev.

IssueInstant - čas nastanka trditve, izražen v UTC.

In naslednje izbirne elemente:

<Conditions> - pogoji, ki jih moramo upoštevati pri ocenitvi veljavnosti trditve. Ta element lahko izpustimo; v tem primeru se oceni, da so pogoji izpolnjeni.

<Advice> - element, ki vsebuje dodatne informacije, koristne v določenih primerih obdelav.

<ds:Signature> - podpis XML za overitev pristnosti trditve. Element je izbiren.

Ter enega ali več naslednjih elementov:

<Statement> - abstrakten sestavljen element, ki je podlaga za druge izpeljane elemente.

<SubjectStatement> - je tudi abstrakten element, ki deduje element <Statement> in ga razširja z elementom <Subject>.

<Subject> - je element, ki podaja uporabnika, na katerega se nanaša trditev. Ta element vsebuje enega ali oba od naslednjih podelementov: <NameIdentifier>, ki je oznaka uporabnika z njegovo varnostno domeno in imenom, ter <SubjectConfirmation>, ki vsebuje podatke, s katerimi je dovoljeno uporabnika overiti. Ta element vsebuje nadaljnje podelemente: <ConfirmationMethod>, <SubjectConfirmationData> in <ds:KeyInfo>.

<AuthenticationStatement> - je element, ki vsebuje informacijo o metodi overitve, času overitve (UTC) ter izbirno domeno DNS in naslovu IP sistema, ki je izvedel overitev. Nazadnje lahko vsebuje informacijo o overitvenih organih, pri katerih lahko ciljno spletno mesto pridobi dodatne informacije o uporabniku, na katerega se nanaša trditev. Deduje element <SubjectStatement>.

<AttributeStatement> - je element, s katerim organ overitve jamči, da ima uporabnik določen atribut ali več njih. Ta element deduje element <SubjectStatement> in ga razširja z elementom <Attribute>. Element <Attribute> nadalje vsebuje elementa <AttributeDesignator> in <AttributeValue>.

<AuthorizationDecisionStatement> - je element, ki vsebuje odločitev organa overitve o pravici uporabnika do uporabe določenega vira. Tudi ta element deduje <SubjectStatement> in ga razširja z atributom "Resource", podanim v obliki URI, in z atributom "Decision", ki lahko zavzame le naslednje vrednosti: Permit (odobreno), Deny (zavrnjeno) in Indeterminate (nedoločeno). <AuthorizationDecisionStatement> lahko izbirno vsebuje še elementa <Action> in <Evidence>. Element <Action> podaja, katere akcije lahko uporabnik izvaja nad posameznim virom. Element <Evidence> vsebuje enega ali več drugih varnostnih trditev ali reference nanje, na podlagi katerih je izdana overitvena odločitev.

Varnostne trditve lahko generirajo in izdajajo samo ustrezni organi SAML. To so npr.:

Microsoft s storitvijo Passport,

XNSORG s platformo spletne identitete (Web Identity) www.xns.org,

DotGNU s platformo Virtual Identity www.dotgnu.org,

ogrodje Liberty www.projectliberty.org.

Protokol SAML

Kot smo že navedli, je varnostne trditve SAML mogoče tvoriti in izmenjevati z različnimi protokoli, vendar se večinoma uporablja protokol zahteva-odgovor (request-response protocol), ki je del specifikacij SAML in razvit posebej v ta namen. V tem, z XML podanem protokolu, sta dva glavna elementa. To sta element <Request>, ki ga tvori odvisna stran (oz. ciljno spletišče), in element <Response>, ki ga tvori izvirno spletišče oziroma stran, ki daje trditve kot odgovor na zahtevo odvisne strani.

Osnova za element <Request> je abstraktni tip "RequestAbstractType", ki vsebuje naslednje obvezne atribute:

RequestID - je oznaka zahteve, ki mora biti unikatna in ki mora biti nato v odgovoru, vsebovana v atributu "InResponseTo".

MajorVersion - glavna različica.

MinorVersion - pomožna različica.

IssueInstant - čas nastanka zahteve, izražen v UTC.

In naslednja izbirna elementa:

<RespondWith>, ki označuje, katera vrsta odgovora ustreza strani, ki zahteva odgovor.

<ds:Signature> je digitalni podpis XML (XML Signature), ki rabi za overitev zahteve.

Element <Request> določa zahtevo SAML in poleg elementov iz <RequestAbstractType> izbirno vsebuje še naslednje elemente:

<Query> je abstraktnega tipa in rabi kot podlaga za izpeljavo novih povpraševanj SAML (queries).

<SubjectQuery> je izpeljan iz <Query>; dodatno vsebuje še referenco na element <Subject> in je prav tako abstraktnega tipa.

<AuthenticationQuery> je element, ki ga uporabljamo za povpraševanja, kot je: "Katere varnostne trditve vsebujejo overitvene izjave (AuthenticationStatement) za tega uporabnika?" Ta element je izpeljan iz elementa <SubjectQuery> in lahko dodatno vsebuje atribut, ki pove, katero metodo overitve zahtevamo.

<AttributeQuery> je element, s katerim lahko v povpraševanjih podamo zahteve, kot je: "Vrni naslednje vrste atributov za tega in tega uporabnika." Ta element deduje po <SubjectQuery> in izbirno dodaja referenco na element <AttributeDesignator> in atribut "Resource". Element <AttributeDesignator> določa, katerega od uporabnikovih atributov naj vrne, atribut XML "Resource" pa, za kateri ciljni vir oziroma storitev.

<AuthorizationDecisionQuery> je element, ki omogoča povpraševanja, kot je: "Sme ta uporabnik izvajati te operacije na tem viru na podlagi danih izkazov (evidence)?" Element razširja <SubjectQuery> z obveznim atributom "Resource" in obvezno referenco na element <Action> ter izbirno referenco na element <Evidence>.

<AssertionIDReference> ena ali več zahtev za trditve, ki imajo tu podane atribute AssertionID.

<AssertionArtifact> ena ali več zahtev za trditve s tu podanimi artefakti.

Z elementom <Response> izvirno spletno mesto odgovori na zahtevo odvisne strani. Podlaga zanj je abstraktni tip "ResponseAbstractType", ki vsebuje naslednje obvezne atribute:

ResponseID - je oznaka odgovora, ki mora biti unikatna.

MajorVersion - glavna različica.

MinorVersion - pomožna različica.

IssueInstant - čas nastanka odgovora, izražen v UTC.

Naslednja izbirna atributa:

InResponseTo - je referenca na zahtevo, na katero ta odgovor odgovarja. Ta atribut je lahko izpuščen le, če odgovor (response) ni nastal zaradi zahteve ali pa v zahtevi ni mogoče prepoznati vrednosti atributa "RequestID".

Recipient - označuje prejemnika, kateremu je namenjen ta odgovor.

Ter izbirni element <ds:Signature> XML Signature, s katerim lahko elektronsko podpišemo odgovor in tako zagotovimo njegovo integriteto.

Element <Response> razširja "ResponseAbstractType" z referenco na element <Status> in nič, eno ali več referenc na element(e) <Assertion>, torej varnostne trditve. Z enim podaja stanje ustrezne zahteve SAML, z drugim pa varnostne trditve, ki so odgovor na zahtevo.

Pri odgovarjanju organa SAML na zahteve mora vsaka varnostna trditev v odgovoru vsebovati vsaj eno izjavo (Statement), v kateri uporabnik (Subject) popolnoma ustreza uporabniku, podanem v zahtevi. Dva uporabnika sta popolnoma enaka, če v primeru, da ima Uporabnik1 element <NameIdentifier>, tudi Uporabnik2 vsebuje enak element <NameIdentifier>, in če ima Uporabnik1 element <SubjectConfirmation>, tudi Uporabnik2 vsebuje enak element <SubjectConfirmation>.

Če nobena varnostna trditev pri organu overitve ne ustreza podani zahtevi, potem element <Response> ne sme vsebovati nobenega elementa <Assertion>, vsebovati pa mora element <StatusCode> (ki je del elementa <Status>) z vrednostjo "Success".

Izvedba protokola SAML

Temeljna izvedba (Binding) protokola SAML je izpeljana s pomočjo spletnih storitev, natančneje SOAP. Kot vemo, je SOAP (Simple Object Access Protocol) sestavljen iz ovojnice, podatkovne glave in telesa sporočila. Komunikacija SAML s pomočjo SOAP je izvedena kot preprost model zahtev (request) in odgovorov (response).

Zahteva. Entiteta SAML, ki zahteva varnostno izjavo, pošlje element SAML <Request> entiteti SAML, ki daje varnostne izjave, v telesu sporočila SOAP. V njem je lahko zgolj zahteva SAML in nič drugega.

POST /SamlService HTTP/1.1

Host: www.example.com

Content-Type: text/xml

Content-Length: nnn

SOAPAction: http://www.oasis-open.org/committees/security

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body>

<samlp:Request xmlns:samlp:="..." xmlns:saml="..." xmlns:ds="...">

<ds:Signature> ... </ds:Signature>

<samlp:AuthenticationQuery>

...

</samlp:AuthenticationQuery>

</samlp:Request>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Primer 1: Zahteva SAML overitvenemu organu (Authentication Authority) po varnostni trditvi z izjavo o pristnosti (Authentication statement).

Odgovor. Entiteta SAML, ki daje izjave, odgovori ali z elementom <Response> znotraj telesa SOAP sporočila ali šifro napake. Znova je lahko v telesu sporočila zgolj element <Response>.

HTTP/1.1 200 OK

Content-Type: text/xml

Content-Length: nnnn

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body>

<samlp:Response xmlns:samlp="..." xmlns:saml="..." xmlns:ds="...">

<StatusCodevalue="samlp:Success"/>

</Status>

<ds:Signature> ... </ds:Signature>

<saml:Assertion>

<saml:AuthenticationStatement>

...

</saml:AuthenticationStatement>

<saml:Assertion>

</samlp:Response>

</SOAP-Env:Body>

</SOAP-ENV:Envelope>

Primer 2: Odgovor organa overitve na zahtevo iz Primera 1.

Obe strani morata zagotoviti naslednje štiri vrste overitve pristnosti (authentication):

1. Brez overitve strežnika ali odjemalca.

2. Temeljna overitev odjemalca HTTP s SSL 3.0 ali TLS 1.0 ali brez.

3. Overitev strežnika HTTP SSL 3.0 ali TLS 1.0 z njegovim potrdilom (server-side certificate).

4. Vzajemna overitev strežnika in odjemalca HTTP SSL 3.0 ali TLS 1.0 s potrdiloma (server-side and client-side certificate).

Vedno, kadar zahtevamo tajnost ali integriteto sporočila, mora stran, ki daje izjave (responder), uporabiti šifriranje SSL 3.0 ali TLS 1.0 s strežnikovim potrdilom.

Prenos informacij med spletišči

Kot smo navedli že na začetku, je SAML definiran z namenom, da omogoči enkratno prijavo (SSO) uporabnikom internetnih storitev. V okviru SAML to vsebuje prijavo na izvirnem spletnem mestu (source site), to je na kakšnem skrbniku identitete (Identity Provider), nato pa uporabo storitev na ciljnih spletnih mestih (destination site) brez vnovičnih prijav. Informacije med dvema spletiščema pri enkratni prijavi prenašamo z običajnim brskalnikom:

1. SAML artefakt: je majhen niz, ki se prenese do ciljnega spletišča in v nadaljevanju s ciljnega spletišča neposredno nazaj na izvirno ter enolično referencira varnostno trditev (assertion).

2. Z obrazcem HTML, posredovanim s "POST": trditve SAML se po potrditvi naložijo v obrazec brskalnika (HTML form) in prenesejo do ciljnega spletišča kot del bremena HTTP POST.

Piškotki se v ta namen ne morejo uporabiti, ker bi v tem primeru obe spletišči morali pripadati isti domeni.

Enkratna prijava z artefaktom SAML

Denimo, da se je uporabnik s pomočjo varnega kanala overil na izvirnem spletišču. Za tem:

Na izvirnem spletišču izbere medspletno storitev prenosa (Inter-Site Transfer Service), to je povezava na ciljno spletišče. Izvirno spletišče tvori ustrezno trditev SAML z artefaktom in jo shrani v svoj predpomnilnik.

Uporabnikov brskalnik se preusmeri na ciljno spletišče, pri čemer posreduje tudi artefakt trditve.

Uporabnik na ciljnem spletišču izbere ustrezno storitev, ciljno spletišče prebere artefakt.

Ciljno spletišče od izvirnega zahteva varnostne trditve, potrebne za uporabo njegovih storitev. Zahteve legitimira z enim ali več artefakti.

Izvirno spletišče odgovori z ustreznimi varnostnimi trditvami.

Ciljno spletišče izvede želeno storitev in rezultat posreduje uporabniku.

Vse te interakcije morajo potekati po varnem kanalu. Nadvse pomembno je, da nepooblaščeni ne pridobijo veljavnega artefakta, saj bi lahko z njegovo pomočjo izvajali storitve (npr. plačevali) na račun legalnega uporabnika.

Enkratna prijava z obrazcem

Vidimo, da sta pri tem postopku dva koraka manj in da izvirno in ciljno spletišče med seboj ne komunicirata neposredno. Če znova predpostavimo, da se je uporabnik že overil na izvirnem spletišču, sledi:

Na izvirnem spletišču izbere medspletno storitev prenosa (Inter-Site Transfer Service), to je povezava na ciljno spletišče.

Izvirno spletišče tvori ustrezen obrazec HTML, v katerem je celotna varnostna trditev (assertion), potrebna za uporabo storitve na ciljnem spletišču.

Uporabnikov brskalnik posreduje obrazec s trditvijo ciljnemu spletišču.

Ciljno spletišče poslano trditev obdela in na tej podlagi uporabniku bodisi odobri ali zavrne izvedbo storitve.

Tudi tu je zaželeno, da komunikacija poteka po varnem kanalu, posebej pomembno je, da nepooblaščeni ne pridobijo varnostne trditve, saj bi lahko z njeno pomočjo izvajali storitve v imenu legalnega uporabnika.

Ker je standard SAML načrtovan le za varno izmenjavo informacij za enkratno prijavo na ločena spletišča, ne opredeljuje, kako izvirna stran oziroma organ generiranja varnostnih trditev izvaja overitev uporabnikov. Uporablja lahko npr. PKI, sekljanje ali gesla.

Še en zgled rabe protokola SAML

<samlp:Request ...>

<samlp:AttributeQuery>

<saml:Subject>

<saml:NameIdentifier

SecurityDomain="sun.com"

Name="ivan"/>

</saml:Subject>

<saml:AttributeDesignator

AttributeName="Dohodek_Delavca"

AttributeNamespace="sun.com">

</saml:AttributeDesignator>

</samlp:AttributeQuery>

</samlp:Request>

Zahteva odvisne strani SAML izdajatelju varnostnih trditev za atribut "Dohodek_Delavca"

<samlp:Response

MajorVersion="1" MinorVersion="0"

RequestID="128.14.234.20.90123456"

InResponseTo="123.45.678.90.12345678"

StatusCode="/features/2004/05/Success">

<saml:Assertion

MajorVersion="1" MinorVersion="0"

AssertionID="123.45.678.90.12345678"

Issuer="Sun Microsystems, Inc."

IssueInstant="2004-01-14T10:00:23Z">

<saml:Conditions

NotBefore="2004-01-14T10:00:30Z"

NotAfter="2004-01-14T10:15:00Z" />

<saml:AuthenticationStatement

AuthenticationMethod="Password"

AuthenticationInstant="2004-01-14T10:00:20Z">

<saml:Subject>

<saml:NameIdentifier

SecurityDomain="sun.com"

Name="ivan" />

</saml:Subject>

</saml:AuthenticationStatement>

</saml:Assertion>

</samlp:Response>

Primer 2: Izdajatelj SAML v odgovoru izjavlja, da se je uporabnik pri njem overil z geslom 14. januarja 2004 ob deseti uri in dvajset sekund po univerzalnem času.

Vidimo, da odgovor ni povsem to, kar smo želeli, med drugim smo od izvirne strani želeli atribut "Dohodek_Delavca" za uporabnika z oznako "ivan", dobili pa smo le izjavo o overitvi. Dobimo namreč vse varnostne trditve, v katerih je uporabnik enak tistemu iz zahteve, ne glede na to, ali gre za overitev, atribut(e) ali odločitev o pravici izvedbe storitve oziroma uporabe vira. V našem primeru atributa morda ni.

Sklep

Označevalni jezik za varnostne trditve, ki temelji na XML, predstavlja infrastrukturo, potrebno za enkratno prijavo na več domensko različnih, čeprav poslovno povezanih spletnih mest. Osnova jezika so varnostne trditve (Security Assertion), ki jih tvorijo izvirne strani. Standard sestavlja še protokol zahteva-odgovor, ki določa, kako lahko odvisna stran preveri uporabnika, ki želi uporabljati njene storitve (ne da bi se tudi pri njej overil), pri izvirni strani. Protokol je v končni fazi izveden s pomočjo spletnih storitev in HTTP, na višji ravni pa izvirna stran, uporabnikov brskalnik in odvisna stran varno izvajajo enkratno prijavo z artefakti ali obrazci HTML/POST.

Več o SAML:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

Naroči se na redna tedenska ali mesečna obvestila o novih prispevkih na naši spletni strani!

SAML - Označevalni jezik za varnostne trditve

Komentirajo lahko le prijavljeni uporabniki