Varne spletne storitve
Protokol HTTPS s svojimi varnostnimi mehanizmi zagotavlja varnost med dvema točkama, WS-Security (Web Services Security) pa zagotavlja varnost od enega konca do drugega, torej vso pot med več spletnimi točkami.
Namen standarda Web Services Security (WS-Security) je zagotoviti mehanizme, s katerimi je mogoče izvesti varno izmenjavo sporočil SOAP. Standard ne podaja novih šifrirnih postopkov in njihove uporabe, temveč predstavlja ogrodje, ki omogoča vzpostavitev varnosti z vsemi znanimi in morebitnimi novimi, še nerazvitimi varnostnimi protokoli. Tako omogoča uporabo: infrastrukture javnih ključev (Public Key Infrastructure - PKI), Kerberos in SSL (Secure Socket Layer) varnostnih modelov. Z WS-Security razširimo protokol SOAP z varnostnimi elementi. Dodane so možnosti za: pošiljanje varnostnih žetonov (Security Tokens), kot dela sporočil, zagotovitev integritete sporočil (Message Integrity) in zagotovitev zaupnosti sporočil. Samo WS-Security ne zagotavlja polne varnostne rešitve za spletne storitve, temveč gre za gradnik, ki ga uporabljajo nadaljnje razširitve spletnih storitev in višjenivojski programsko specifični protokoli, kot so: WS-Policy, WS-SecurityPolicy, WS-Trust, WS-Addressing, WS-SecureConversation, SAML, XrML in drugi. Enotno ime tega nabora protokolov za spletne storitve je GXA (Global XML web services Architecture).
Varnostni žetoni
Za naslovnika oziroma ponudnika storitev je zelo pomembno, da ve, kdo je pošiljatelj sporočila - poznati mora njegovo identiteto. Prejemnik ne more biti prepričan glede pošiljateljeve identitete, če je ne more na neki način preveriti, saj bi se lahko pošiljatelj predstavil za nekoga drugega. Tako je najpomembnejši namen varnostnih žetonov, da prejemnik sporočila lahko preveri istovetnost pošiljatelja. Varnostni žeton je lahko sestavljen npr. iz uporabniškega imena in gesla, listka kerberos (ticket), certifikata X.509, ali česa drugega. V primeru uporabniškega imena je istovetnost potrjena z geslom, pri listku kerberos prejemnik preveri veljavnost s ključem izdajatelja, pri certifikatu lahko podamo referenco na izdajatelja (CA -Certificate Authority).
WS-Security ne določa, kako izvesti preverjanje istovetnosti, temveč definira, kako je mogoče prejemniku prenesti nabor različnih varnostnih žetonov, te lahko nato uporabi. kakor hoče. Čeprav je mogoče uporabiti poljuben žeton, so zaenkrat določeni že omenjene vrste. Žeton z uporabniškim imenom in geslom je najenostavnejša izbira in je definiran z elementom <UsernameToken>. (Glej izpis 1.)
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<s:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>Peter</wsse:Username>
<wsse:Password>mY5ecRet</wsse:Password>
</wsse:UsernameToken>
...
</wsse:Security>
</s:Header>
<s:Body>
...
</s:Body>
</s:Envelope>
Izpis 1: Varnostni žeton z uporabniškim imenom in geslom
Kot vidimo, sta poleg sheme XML za ovojnico SOAP podani še shemi secext in utility, določeni z WS-Security. Glavni element v shemi secext (wsse) je <Security>. Takega dokumenta (z geslom) v praksi seveda ne smemo poslati v omrežje nezavarovanega, zato moramo uporabiti SSL ali IPSec.
Uporaba elementa <SecurityTokenReference>
Preglejmo načine uporabe in obdelavo tega elementa. Uvajamo ga zaradi naslednjih razlogov:
Reference podpisa XML lahko vsebujejo vidike, ki niso primerni za vse reference.
Poglejmo zglede, ki so podlaga zgornjim razlogom:
Lokalna referenca (Local Reference) - varnostni žeton je vključen v glavo elementa <Security> in povezan s podpisom XML.
Oddaljena referenca (Remote Reference) - varnostni žeton ni del sporočila, temveč je dosegljiv na podani lokaciji URI in povezan s podpisom XML.
Oznaka ključa (Key Identifier) - varnostni žeton je označen z znano vrednostjo, ki je rezultat dobro znane (well-known) funkcije z varnostnim žetonom kot argumentom in je povezan s podpisom XML.
Ime ključa (Key Name) - varnostni žeton, povezan s podpisom XML, identificiramo s podanim imenom (v našem primeru je žeton na oddaljeni lokaciji).
Reference specifičnih formatov (Format-Specific Reference) - varnostni žeton je identificiran s posebej zanj določenim mehanizmom ter povezan s podpisom XML.
Reference brez podpisa XML (Non-Signature References) - sporočilo lahko vsebuje vsebino XML, ki ni podpis XML, vseeno pa lahko referencira varnostni žeton, ki je ali ni del sporočila.
Druga specificirana izbira za posredovanje identitete je varnostni žeton, v katerem je listek kerberos. Tudi v tem primeru se žeton pošlje v glavi sporočila SOAP znotraj elementa <Security>. (Glej izpis 2.)
...
<wsse:Security>
<wsse:BinarySecurityToken
ValueType="wsse:Kerberosv5ST"
EncodingType="wsse:Base64Binary">
QMwcAG ...
</wsse:BinarySecurityToken>
</wsse:Security>
...
Izpis 2: Varnostni žeton z listkom kerberos
Vidimo, da se listek kerberos prenaša z elementom <BinarySecurityToken>, da gre za kerberos, je določeno z atributom ValueType, določen je še atribut EncodingType, ki podaja kodirno shemo, vsebina pa je listek sam (podano je le nekaj prvih znakov).
Tretja, zaenkrat zadnja specificirana izbira za varnostni žeton je certifikat X.509. Podana je zelo podobno kot predhodna, razlikuje se le v atributu ValueType (in seveda vsebini). (Glej izpis 3.)
...
<wsse:Security>
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary">
KkFPle ...
</wsse:BinarySecurityToken>
</wsse:Security>
...
Izpis 3: Varnostni žeton s certifikatom X.509
Poleg teh treh vrst neposrednega vstavljanja varnostnih žetonov v samo sporočilo, WS-Security podaja tudi element <SecurityTokenReference>, s katerim lahko povemo, kje je varnostni žeton. To je lahko še vedno kje znotraj sporočila SOAP, lahko pa tudi kjerkoli v medmrežju. Ta element lahko vsebuje več različnih vrst referenc. Najbolj specifična je neposredna - z elementom <Reference>, ki jo podamo z atributom URI, ki, kot pove ime, podaja URI (Uniform Resource Identifier), na katerem je varnostni žeton. Naslednja definirana vrsta reference na žeton je oznaka ključa (Key Identifier), ki je podana z zakrito vrednostjo (opaque value). Z njo lahko nedvoumno identificiramo žeton in je običajno predstavljena z zgoščeno vrednostjo (hash) ustreznih delov žetona. Ustrezen element v sporočilu je <KeyIdentifier>.
Naslednji način referenciranja je z oznako ključa (key name). To omogoča referenciranje žetona z nizom, ki ustreza imenu identitetne trditve (identity assertion), vsebovane v žetonu. Taki referenci lahko ustreza več žetonov.
WS-Security in SAML
Trditev SAML (Security Assertion Markup Language Assertion) je varnostni žeton, ki temelji na XML. Tako trditev lahko v sporočilo SOAP vstavimo neposredno v element <Security>:
<S:Envelope xmlns:S="...">
<S:Header>
<wsse:Security xmlns:wsse="...">
<saml:Assertion
MajorVersion="1"
MinorVersion="0"
AssertionID="SecurityToken-ef375268"
Issuer="elliotw1"
IssueInstant="2004-07-23T11:32:05.6228146-07:00"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
...
</saml:Assertion>
<ds:Signature xmlns:ds="...">
...
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<saml:AssertionIDReference>
SecurityToken-ef375268
</saml:AssertionIDReference>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
...
</wsse:Security>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
Izpis: Zgled SAML XML varnostnega žetona
WS-Security določa atribut wsu:Id kot mehanizem za referenciranje varnostnih žetonov. Tega ni mogoče uporabiti za SAML trditve, saj SAML ne dopušča razširitve atributov za <saml:Assertion> element, zato za referenciranje uporabljamo <saml:AssertionIDReference> element, ki ga postavimo v <SecurityTokenReference> element. Ko prejemnik naleti na tako strukturo, mora najti ustrezno SAML trditev (če je SAML ustrezen) in jo uporabiti kot varnostni žeton. Na ta način uporabljamo WS-Security za SAML.
http://www.oasis-open.org/committees/download.php/7837/WSS-SAML-15.pdf
Zadnja vrsta referenciranja je izvedena z vstavljeno referenco (embedded reference), ki omogoča vstavljanje žetonov, v nasprotju s kazalci na žetone, ki so nekje drugje. Podamo jo z elementom <Embedded>. Zgled take reference je npr. vstavljena trditev SAML (SAML Assertion).
Celovitost sporočil
Z zagotovitvijo celovitosti (integrity) sporočil dosežemo, da dobi prejemnik točno tako sporočilo, kakršno je pošiljatelj poslal. V ta namen enako kakor v drugih podobnih primerih uporabljamo elektronski podpis (digital signature). Ker gre v bistvu za dokument XML, je najprimernejša oblika že standardizirana tehnologija podpis XML (XML Signature), ki je le rahlo dopolnjena za uporabo v SOAP sporočilih. Zgled uporabe podpisa XML v sporočilu SOAP je v izpisu 4.
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<s:Header>
<wsse:Security>
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
wsu:Id="X509Cert">
KkFPle ...
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14N"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#TeloSporocila">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
aOb4Luuk...
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
A9qqIrtE3xZ...
</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#X509Cert"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</s:Header>
<s:Body wsu:Id="TeloSporocila">
...
</s:Body>
</s:Envelope>
Izpis 4: Zgled zagotavljanja celovitosti sporočila
Na začetku imamo varnostni žeton s certifikatom X.509, ki je predstavljen v elementu <BinarySecurityToken>; ta poleg drugega vsebuje tudi atribut Id (iz sheme utility), s katerim ga označimo, da ga je mogoče referencirati. Sledi mu element <Signature> in njegovi podelementi, s katerimi uporabimo elektronski podpis XML. Podana je metoda za standardizacijo (CanonicalizationMethod), metoda za podpis (SignatureMethod), s katero šifriramo izvleček (digest). Nato imamo element <Reference>, s katerim podamo referenco na vsebino, ki jo podpisujemo. Zatem imamo metodo, s katero iz vsebine naredimo izvleček. V našem primeru je izvleček narejen iz telesa sporočila (kot vsebina elementa <DigestValue>). Sledi mu šifrirana vrednost tega izvlečka (kot vsebina elementa <SignatureValue>), ki predstavlja bistvo podpisa. Naslednji element je <KeyInfo>, v katerem podamo ključ za dešifriranje vsebine v elementu <SignatureValue>. V našem primeru je podana neposredna referenca na varnostni žeton, ki je v našem sporočilu takoj na začetku elementa <Security>.
WS-Security omogoča podajanje več podpisov v okviru istega sporočila, ki so lahko namenjeni različnim vmesnim prejemnikom na poti sporočila do končnega prejemnika. Z WS-Security lahko elektronsko podpišemo tudi same varnostne žetone.
Šifriranje sporočil
Pogosto nam ni dovolj, da ne more nihče spremeniti sporočila med njegovo potjo, ne da bi to opazili, temveč tudi zahtevamo, da ga nihče nepooblaščen ne more razumeti, hočemo torej, da je tajno. Tako kot pri celovitosti tudi tu uporabljamo že uveljavljeno varnostno tehnologijo, to je šifriranje XML (XML Encryption). To ni posebej zapleten standard, delno uporablja že znani podpis XML, v WS-Security uporabljamo le elemente <EncryptedData>, <EncryptedKey> in <ReferenceList>. Od teh je najpomembnejši <EncryptedData>, ki vsebuje <CipherData>, ki lahko nadalje vsebuje podatek o uporabljenem šifrirnem algoritmu, uporabljenem ključu in seveda same šifrirane podatke.
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<s:Header>
<wsse:Security>
<xenc:EncryptedKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo>
<ds:KeyName>
CN=Key13, C=US
</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>
ir4DfG ...
</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#SifriranoTelo"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
</wsse:Security>
</s:Header>
<s:Body>
<xenc:EncryptedData wsu:Id="SifriranoTelo">
<xenc:EncryptionMethod
Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/>
<xenc:CipherData>
<xenc:CipherValue>
r5KipsDV ...
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</s:Body>
</s:Envelope>
Izpis 5: Zgled šifriranja SOAP sporočila
V izpisu 5 poleg šifriranih podatkov pošiljamo še ključ, s katerim smo šifrirali podatke. Pri tem je šifrirni ključ znotraj elementa <EncryptedKey>. Šifrirna metoda <EncryptionMethod> je RSA, kar pomeni asimetrično šifriranje (z javnim ključem prejemnika sporočila). Sledi podatek o imenu simetričnega ključa (<KeyName>), podan v obliki LDAP, in šifrirana vrednost samega ključa (<CipherValue>). Nazadnje imamo znotraj elementa <EncryptedKey> še referenco na podatke (<DataReference>), ki jih ta ključ šifrira. V telesu sporočila so v našem primeru šifrirani podatki (v okviru elementa <EncryptedData>), element <EncryptedMethod> podaja metodo, s katero so šifrirani, v našem primeru je to trojni DES simetrični algoritem. Nazadnje so v okviru elementa <CipherValue> šifrirani sami podatki.
Arhitektura globalnih spletnih storitev XML (GXA)
GXA je nastal na podlagi iz delavnice o bodočem razvoju spletnih storitev konzorcija W3C aprila 2001, najpomembnejši avtorji specifikacij so podjetja Microsoft, IBM, Verisign, BEA Systems, RSA Security in SAP.
Struktura najpomembnejših skupin protokolov GXA
Kot vidimo na sliki, je protokol WS-Security obvezen, saj je podlaga za druge, ki jih lahko vključujemo po potrebi, vse ali samo nekatere. V skupini "politika" (Policy) sta protokola WS-Policy in WS-SecurityPolicy, s katerima podjetje določi varnostno strategijo spletnih storitev. V skupini "zaupanje" (Trust) je protokol WS-Trust, s katerim določimo izdajanje varnostnih žetonov in upravljamo odnose zaupanja med partnerji. V skupini "usmerjanje" (Routing) so protokoli za usmerjanje sporočil SOAP s prenosnimi protokoli, kot so TCP, UDP in HTTP. Eden od teh protokolov je WS-Routing, ki pa prihaja iz rabe; nadomeščamo ga s protokolom WS-Addressing. Poleg tega je iz te skupine pomemben še protokol WS-Referral, ki se uporablja za brisanje, vstavljanje in iskanje usmerjevalnih vnosov v SOAP usmerjevalniku. V skupini "koordinacija" (Coordination) sta pomembna protokola WS-Transaction za izvajanje transakcij s spletnimi storitvami in WS-Coordination, ki rabi za podporo prvemu. V skupini "federacija" (Federation) je najpomembnejši protokol WS-Federation, s katerim lahko povezujemo posamezne varnostne entitete spletnih storitev. Dovoljuje in posreduje zaupanje (trust) identitete, atributov in overitev. Tako je to lahko alternativa SAML in Liberty (ker pa z njima ni združljiv, podjetja odlašajo z implementacijo povezovanja po teh standardih in čakajo, da se bodo zlili). V skupini "inšpekcija" (Inspection) je protokol WS-Inspection, s katerim preiskujemo spletna mesta, da bi poizvedeli, katere storitve vsebujejo. Končno skupina "ograjevanje sporočil" (Message Encapsulation) vsebuje protokol DIME (Direct Internet Message Encapsulation), s katerim določamo binarne oblike pakiranja sporočil SOAP in njihovih priponk.
V okviru WS-Security je mogoče uporabiti šifriranje XML na več načinov, lahko šifriramo celotno telo, telo in del glave, samo dele telesa, pa tudi sporočilu pripete podatke (attachments). Različni prejemniki sporočila lahko dodajajo svoje šifrirane glave in dešifrirajo ter obdelajo njim namenjene dele.
Časovne znamke
Za prejemnika sporočila SOAP je pogosto pomemben podatek, kako staro je sporočilo. Če je starejše od nekega intervala, se ob procesiranju zavrže, saj ga lahko nepooblaščeni uporabi za ponovitveni napad (replay attack). Sama sinhronizacija časa med vpletenimi stranmi ni del specifikacije. Priporočeno je, da so časovne znamke izražene s tipom XML Schema dateTime in izražene v univerzalnem času (UTC Time), ki naj ne bo natančnejši od tisočinke sekunde. Če že uporabimo drugačen časovni format, ga moramo podati z atributom ValueType. V izpisu 6 je podan zgled časovne znamke.
<S:Envelope xmlns:S="..." xmlns:wsse="..." xmlns:wsu="...">
<S:Header>
<wsse:Security>
<wsu:Timestamp wsu:Id="CasovnaZnamka">
<wsu:Created>2003-09-13T08:42:00Z</wsu:Created>
<wsu:Expires>2003-10-13T09:00:00Z</wsu:Expires>
</wsu:Timestamp>
...
</wsse:Security>
...
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
Izpis 6: Zgled časovne znamke
Kot vidimo, je časovna znamka podana z elementom <Timestamp>. Element <Created> kaže čas, ko je bilo sporočilo pripravljeno za prenos (serialized for transmission), element <Expires> pove, kdaj varnostni elementi sporočila nehajo veljati. Po tem času je najbolje zavreči celotno sporočilo.
Grožnje varnosti
Elektronski podpis ne jamči varnosti sporočil, tretji lahko posname podpisano sporočilo in ga pozneje znova pošlje (replay attack). Zato je priporočljivo v sporočilo vključiti elektronsko podpisane elemente, ki prejemniku omogočajo zaznavanje tega napada. Najbolj znani so: uporaba časovnih znamk, zaporedna številka, elementi, ki prenehajo veljati, in korelacija sporočil.
Sklep
WS-Security ne vpeljuje novih varnostnih tehnologij, temveč samo tvori ogrodje, s katerimi omogoča uporabo obstoječih tehnologij. Ker so SOAP sporočila v bistvu dokumenti XML, sta za njihovo varnost najpomembnejša standarda podpis XML, s katerim zagotavljamo integriteto, in šifriranje XML, s katerim zagotavljamo zaupnost sporočil. Tretji pomemben del WS-Security so varnostni žetoni: z njimi prejemniki sporočil preverijo identiteto pošiljatelja. Sporočila SOAP pogosto potujejo prek več posrednikov (ki sami obdelajo del sporočila), zato imamo lahko več varnostnih žetonov ter podpisnih in šifrirnih elementov.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss