Sunteți pe pagina 1din 29

INTEGRAREA APLICATIILOR PRIN SERCICII

SOA i Servicii Web


Muli cred c "SOA" i "Serviciile Web" sunt sinonime, iar SOA ar avea nevoie de
serviciile Web pentru a putea fi implementat. Aceast nelegere este total greit, SOA fiind o
paradigm, iar serviciile Web reprezentnd o tehnologie de implementare [92]. Confuzia apare
deoarece serviciile Web sunt considerate standardul de-facto pentru realizarea SOA urilor, dar
exist i alte posibiliti [173].
Treptat, modelul de prelucrare client-server, specific primelor aplicaii n reea, a fost transformat
ntr-un model bazat pe niveluri de servicii [72]. Considerate ca fiind viitorul Internetului,
serviciile Web sunt colecii de standarde XML care permit interaciunea ntre sisteme (programe),
independente de platforma i tehnologie. Rolul serviciilor Web este de a partaja date i de a
accesa diverse servicii, oferind clienilor o singur interfa public [74].
Principalele avantaje ale serviciilor Web sunt legate de flexibilitate i versatilitate: ele suport o
mulime de arhitecturi i sunt independente de platforme i modele. Serviciile Web sunt
construite pe mai multe tehnologii care lucreaz n colaborare cu standardele n curs de
dezvoltare pentru asigurarea securitii, precum i pentru a se asigura c pot fi combinate pentru a
lucra independent de un furnizor. De asemenea, serviciile Web ctig pe uurina dezvoltrii i a
interoperabilitii.

Ele

ofer

un

cadru

promitor

pentru

dezvoltarea,

integrarea

interoperabilitatea aplicaiilor software distribuite. Tehnologia serviciilor Web permite


interaciunea dintre componente software aflate n afara granielor organizaionale. ntr-un astfel
de mediu distribuit este foarte important pentru a elimina erorile din faza de proiectare, nainte ca
serviciile s fie implementate [252], [254], [255].
n seciunile urmtoare vom prezenta, pe scurt, cteva noiuni de baz ale ambelor concepte
(principii, beneficii, caracteristici, protocoale/standarde, cerine fundamentale de securitate,
standarde de securitate), cu scopul de a nelege ameninrile de securitate cu privire la serviciile
Web.

2.1.

SOA
Exist mai multe definiii ale SOA, iar n opinia organizaiei OASIS ( Organization for the

Advancement of Structured Information Standards) reprezint "o paradigm pentru organizarea


i utilizarea capabilitilor distribuite care pot fi sub controlul diferitor domenii de proprietate.
Aceast paradigm furnizeaz mijloace uniforme pentru a oferi, a descoperi, a interaciona i a
folosi capabilitile cu scopul de a produce efectele dorite compatibile cu condiiile prealabile"
[191], [258]. Conform Tanenbaum, un sistem distribuit este o colecie de calculatoare
independente care reuesc s fie percepute de ctre utilizatorii umani ca un sistem unic i coerent.
n SOA, resursele sunt puse la dispoziia altor participani n reea sub form de servicii
independente care sunt accesate ntr-un mod standardizat. Astfel, este furnizat un cuplaj mai
flexibil al resurselor dect n arhitecturile sistemelor tradiionale [252], [256]. Unul dintre
obiectivele de baz al SOA este de a produce componente reutilizabile, fiecare dintre acestea
ncapsulnd logica diferit. Orientarea pe servicii (BPM Business Process Management, EAI Enterprise Application Integration, AOP - Aspect Oriented Programming) are multe rdcini n
orientarea pe obiecte (Dezvoltare modular, programare procedural, RPC Remote Procedure
Call) i a fost influenat de evoluia sistemelor tradiionale aa cum este redat n figura 2.1.

Figura 2.1 Evoluia de la sistemele tradiionale la cele orientate pe servicii(prelucrare dup


[124])

SOA este o form a arhitecturii sistemelor distribuite, iar mai multe organizaii i corporaii de la
nivel internaional, printre care W3C, Microsoft, IBM - International Business Machines, OASIS
au publicat propriile lor principii cu privire la SOA [18], [82], [96], [124], [191], [252], [254],
dintre care amintim:
Vedere logic. Serviciul este un abstract, o vedere logic de programe reale, baze de date,
procese de afaceri etc., de obicei desfoar operaii la nivel de afaceri.
Orientare spre mesaj. Formal, serviciul este definit n termeni de mesaje schimbate ntre
furnizor i solicitant, dar nu depinde de proprietile acestora.
Orientare spre descriere. Un serviciu este descris de o main-procesabil de metadate.
Descrierea refer caracterul public al SOA: doar acele detalii care sunt expuse public i
care sunt importante pentru folosirea serviciului ar trebui s fie incluse n descriere.
Semantica unui serviciu ar trebui s fie documentat, fie direct, fie indirect, prin
descrierea sa.
Abstractizarea. Contractele de servicii conin doar informaii eseniale despre servicii i
informaiile despre servicii sunt limitate la ceea ce este publicat n contracte.
Granularitate. Serviciile tind s foloseasc un numr mic de operaii cu mesaje relativ
mari i complexe.

Orientare reea. Serviciile tind s fie orientate spre utilizarea printr-o reea, dei acest
lucru nu este o cerin absolut.
Interoperabilitate / platforma neutr. Mesajele sunt trimise ctre o platform neutr, ntrun format standardizat prin intermediul interfeelor publice. XML este formatul cel mai
adecvat care ndeplinete aceast constrngere.
Distributivitate. Serviciile componente pot fi consumate de aceeai main sau distribuite
pentru mainile de la distan. Interfaa serviciului i logica sunt independente de
protocoalele folosite pentru transport, respectiv acces la serviciu.
Cutie neagr / ncapsularea. Serviciile sunt un fel de "cutie neagr" pentru consumatorii
acestora, n sensul ca implementarea acestora este ascuns de consumatorii finali.
Autonomia. Serviciile au control asupra logicii pe care o ncapsuleaz, de la design-time
pn la run-time.
Contractul. Serviciile i expun interfeele publice prin intermediul contractelor, astfel c
consumatorii de servicii au acces la acces la descrierile serviciilor prin contracte.
Componenialitate. Un serviciu poate fi la rndul su compus din mai multe componente,
chiar i alte servicii, care pot fi versionate i administrate n mod independent.
Asamblarea. Serviciile pot fi asamblate de o aplicaie cu scopul de a efectua operaii mai
complexe sau s adopte un proces de afaceri.
Cuplare slaba. Serviciile menin o relaie care minimizeaz dependinele de alte aplicaii
i necesit s menin doar o relaie de contientizarea fa de cellalt.
Descoperirea. Serviciile i public metadatele pe baz de WSDL - uri prin care acestea
pot fi descoperite i consumate n mod eficient.
Reutilizarea. Logica de business este mprit n servicii cu scopul de a promova
reutilizarea acestora.
Principiile care stau la baza SOA sunt ilustrate n figura 2.2, de mai jos.

Figura 2.2 Triunghiul SOA


Modelul SOA trateaz trei elemente principale care acioneaz ca un ciclu: gsire legare /
invocare - nregistrare (find - bind/invoke register).
Furnizorul de servicii (Service Provider) ofer un anumit serviciu i public descrierea
serviciului (Register) ntr-un registru de servicii (Registry).
Solicitantul de serviciu (Service Requester) interogheaz registrul de servicii pentru a gsi
un anumit serviciu (Find).
Dac serviciul cutat va fi gsit n registrul de servicii (Registry), atunci solicitantul de
serviciu va regsi locaia serviciului i se va lega ( Bind) la endpoint ul acestuia, n final
putnd invoca (Invoke) operaiile serviciului.
n opinia noastr, comparativ cu modelul tradiional client/server, putem spune c furnizorul de
servicii se comport ca un server, iar solicitantul de servicii ca un client.
Conform lui Thomas Erl, n [44] sunt descrise patru tipuri de SOA, precum i legturile
dintre acestea: Service Architecture, Service Composition Architecture, Service Inventory
Architecture i Service-Oriented Enterprise Architecture.
Cele mai multe critici referitoare la arhitecturile SOA au fcut referire la layer-ul XML,
deoarece parsarea XML-urilor poate ncetini puterea de procesare i creste costurile [159].
Tehnologiile actuale care implementeaz SOA (WCF Windows Communication Foundation,
JBI Java Business Integration, DDS Data Distribution Service) au putere de procesare
ridicat.

2.2.

Servicii Web
Serviciile Web reprezint convergena dintre SOA i Web, ele preiau cele mai bune

caracteristici ale SOA i le combin cu Web-ul. Spre deosebire de aplicaiile software tradi ionale
care sunt accesibile prin intermediul protocoalelor proprietare sau tradiionale ( COM
Component Obect Model, DCOM - Distributed Component Object Model, COM+, RPC, RMI
Remote Method Invocation etc), serviciile Web sunt accesate prin intermediul protocoalelor Web
omniprezente (HTTP - Hypertext Transfer Protocol, HTTPS HTTP Secure). Ele pot fi vzute ca
un set de standarde folosite la interoperabilitatea dintre aplicaii care comunic n cadrul unei

reele sau, conform organizaiei World Wide Web Consortium (W3C)1 [10], "Un serviciu Web
este un sistem software identificat printr-un URI [RFC-2396] ale crui interfee publice i
legturi sunt descrise folosind XML. Definirea sa poate fi descoperit de alte sisteme software.
Aceste sisteme software pot interaciona cu serviciul web ntr-o manier prescris de definirea
sa, avnd la baz mesaje XML transmise prin protocoale din Internet.".
n opinia noastr, serviciile Web sunt aplicaii independente de platforma i tehnologie, bazate pe
standardul universal XML, folosite la interoperabilitatea dintre aplicaii aflate pe platforme
diferite.
Prima iniiativ de construire a serviciilor web a fost anunat n jurul anului 2000 i a avut la
baz mai muli gigani software: IBM, HP - Hewlett Packard, Sun, Oracle i Microsoft. Aceast
iniiativ avea la baz ideea de cumprare, n viitor, de ctre companii a tehnologiilor software de
la aceti gigani sub forma de servicii furnizate prin Internet (IBM Web services, HP e-speak, Sun
Open Network Environment ONE, Oracle network services, Microsoft .NET), dect s dein i
s menin propriile soluii software i hardware [85], [237]. Ca rezultat al acestor eforturi
colaborative, W3C a publicat specificaiile serviciilor web [212].
n esen, serviciile Web se caracterizeaz prin urmtoarele [18], [80], [134]:

Pot fi accesibile pe Web.


Sunt autonome.
Sunt slab cuplate.
Comunic folosind standardul XML. Acesta este independent de platform i neutru de

limbaj de programare permind astfel o integrare uoar.


Sunt proiectate folosind interfee (contracte) care pot fi apelate din alte programe.
Aceast interfa de aplicaie-la-cerere poate fi invocat de orice tip de aplicaie client
sau serviciu.
Sunt nregistrate n registrele serviciului Web, care permit programelor utilizator de
registru s gseasc serviciile de care au nevoie.
Comunic prin trimiterea de mesaje n format clar sau criptat.
Pot fi dezvoltate i implementate pe orice platform.
Toate aplicaiile de servicii web utilizeaz acelai standard, XML, pentru a-i publica
interfeele i pentru a-i codifica mesajele.

http://www.w3c.org

Dintre principiile SOA descrise n seciunea anterioar, autonomia, cuplarea slab i contractul
pot fi considerate ca principii de baz ale serviciilor Web [18]. Serviciile sunt autonome, n sensul
c:
Ar trebui s aib controlul asupra propriilor date.
Au control asupra logicii pe care o ncapsuleaz.
Nu expun logica i altor servicii.

Comunicarea dintre servicii ar trebui s se fac prin intermediul contractelor.

2.2.1. Protocoale i standarde de baz ale serviciilor Web


Exist mai multe standarde cu privire la serviciile Web specificate de organizaii
internaionale de standardizare, precum W3C, Organization for the Advancement of Structured
Information Standards (OASIS)2 i Web Services Interoperability Organization (WS-I)3, ns
numai cinci dintre ele sunt fundamentale. n figura 2.3 am prezentat standardele de baz ale
serviciilor Web, precum i legtura dintre acestea [254], [256].

Figura 2.3 Standardele de baz ale serviciilor Web

1)

Standardul XML

Extensible Markup Language (XML) permite structurarea informaiei ntr-un mod ierarhic prin
folosirea tag urilor, ncorpornd sensul semantic n el. XML este un subset al SGML (Standard
Generalized Markup Language) [81], care are ca obiectiv principal definirea unui formalism care
s permit schimbul uor al documentelor/mesajelor complexe pe Web, depind limitele impuse
prin HTML. El a fost proiectat pentru descrierea datelor i se concentreaz asupra structurii
acestora. XML poate fi folosit pentru a descrie modele, formate i tipuri de date, fcnd astfel
<client>
mai
uor schimbul de date dintre aplicaii.

<endpoint address="http://sdumitra:8080/CreditCardService:8081/CreditCardService.svc"

binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ICreditCard"
http://www.oasis-open.org
contract="CreditCardService.ICreditCard" name="WSHttpBinding_ICreditCard">
3
http://www.ws-i.org
<identity>
2

<certificateReference storeLocation="CurrentUser"
storeName="TrustedPeople"
x509FindType="FindBySubjectName"
findValue="CreditCardService.com"/>
</identity>
</endpoint>
</client>

Listarea 2.1 Exemplu de structur XML


n exemplul de mai sus, listarea 2.1, am redat o structur XML care conine configuraia unui
solicitant de serviciu specificat prin tagul <client>. Datele pentru accesarea serviciului (address binding contract ABC - ul endpoint - ului) sunt specificate n tagul <endpoint>. Valoarea
atributului address, "", reprezint locaia serviciului CreditCardService; valoarea atributului
binding, wsHttpBinding, ne arat modul n care se realizeaz legtura la serviciu, adic
folosind protocolul web HTTP; valoarea atributului contract specific contractul serviciului;
valoarea atributului name identific, n mod unic, n cadrul documentului XML, endpoint-ul
serviciului; valoarea atributului bindingConfiguration indic referina ctre o alt structur XML
n care sunt specificate anumite caracteristici ale legturii wsHttpBinding. n tagul <identity>
este specificat identitatea serviciului (certificat X.509 identificat dup valorile atributelor
storeLocation, storeName, x509FindType, findValue) care urmeaz a fi accesat i identitatea pe
care clientul o va prezenta la invocare.
Regulile cu privire la structura unui document XML (elemente i atribute), precum i la
locaia unde acestea apar n document pot fi documentate ntr-o schem. O schem poate fi
echivalat cu un tip de definire ntr-un limbaj de programare. De asemenea, schemele XML
valideaz documentele XML. Au fost propuse mai multe scheme cu diferite niveluri de
expresivitate: RELAX [46], [260], TREX [47], SOX [205]. Cea mai susinut schema XML a
fost DTD (Document Type Definition), definit doar de specificaiile XML. Datorit limitrilor
de sintax ale DTD, W3C a definit W3C XML Schema Language [254].
XML fiind independent de platform i de limbaj este o alegere natural pentru construirea unor
sisteme interoperabile prin intermediul serviciilor web. Astfel, el devine un format universal
pentru interschimbarea datelor.
O serie de informaii cu privire la avantajele aduse de standardul XML se pot gsi la [155], [254],
[235].

2)

Protocolul HTTP

Hypertext Transfer Protocol (HTTP) este un protocol la nivel de aplica ie pentru sisteme
distribuite, colaborative i hipermedia [204]. El este folosit nc din anul 1990 la nivel de World
Wide Web ca i standard cerere/rspuns pentru schimbul de informaii dintre server i client. Prin
intermediul protocolul HTTP este posibil transmiterea mesajelor SOAP (Simple Object access
Protocol) ntre solicitantul de serviciu i furnizorul de serviciu (client i server). Pe lng
protocolul HTTP, pentru transferul mesajelor SOAP mai pot fi folosite i alte protocoale, precum:
FTP File Transfer Protocol, SMTP - Simple Mail Transfer Protocol, TCP - Transmission
Control Protocol, MSMQ - Message Queuing.

3)

Protocolul SOAP

Simple Object Access Protocol (SOAP) a fost dezvoltat iniial de Microsoft, Developmentor i
Userland [35], [147], [206]. Ulterior, IBM i Lotus au contribuit la o specificaie revizuit care a
dus la versiunea SOAP 1.1 i publicat n aprilie 2000. Aceast specificaie a fost larg acceptat
n ntreaga industrie i a stat la baza mai multor implementri open source interoperabile. WS-I la adoptat ca parte a profilului su de baz [215]. Versiunea actual este SOAP 1.2, iar diferenele
dintre SOAP 1.1 i SOAP 1.2 sunt descrise pe larg n [254].
Serviciile Web folosesc SOAP - ul ca mecanism de transfer al mesajelor ntre servicii descrise de
interfee WSDL. Acest concept este ilustrat n figura 2.4 de mai jos.

Figura 2.4 Reeaua logic a serviciilor Web (prelucrare dup [43])


Rolul SOAP - ului este de a codifica datele n format XML i pentru a face posibil schimbul de
mesaje ntre aplicaii dintr-un mediu distribuit, n format XML. Acesta utilizeaz modelul cerererspuns, unde cererea este dat de ctre clientul SOAP, iar rspunsul este dat de ctre furnizorul

de serviciu, numit server SOAP. Protocolul este folosit att pentru a trimite, ct i pentru a
recepiona mesaje de la serviciul Web. Un avantaj este acela de a ngloba funcionalitatea RPC ului (Remote Procedure Call), folosind extensibilitatea i funcionalitat2ea XML.
Modelul de procesare SOAP asigur c un mesaj SOAP provine de la un expeditor iniial SOAP
i este trimis la un receptor final SOAP traversnd zero sau mai multe noduri intermediare SOAP.
Un mesaj SOAP este unitatea de baz pentru comunicarea ntre noduri SOAP. El const din patru
elemente, ilustrate n figura 2.5 de mai jos:
Anvelopa (Envelope) partea cea mai exterioar a mesajului i l identific pe acesta ca
fiind un mesaj SOAP i nu alt tip de mesaj. Ea conine zero sau mai multe antete SOAP i
corpul SOAP.
Antetul (Header) ofer o modalitate de a aduga extensii definite de utilizator la
mesajul SOAP. El conine informaii generale cu privire la securitate autentificare,
autorizare i sesiune (sub forma de token - uri), precum i informaii cu privire la
prelucrarea mesajului prin nodurile intermediare. Datele referitoare la autentificare, de
obicei sunt criptate folosind standardul WS-Security (XML Encryption, XML Signature).
Corpul (Body) nu lipsete niciodat i conine informaii ce urmeaz a fi transferate ntre
aplicaii.
Defect (Fault) este folosit pentru a raporta o eroare sau informaii specifice erorii. Face
parte din elementul SOAP body i poate lipsi din cadrul elementului sau poate fi numai
unul sigur4.

Figura 2.5 Structura unui mesaj SOAP (prelucrare dup [43])


4

https://msdn.microsoft.com/en-us/library/ms732013%28v=vs.110%29.aspx

n exemplele urmtoare am redat dou mesaje SOAP, unul de tip cerere (SOAP request), iar altul
de tip rspuns (SOAP response).

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">


<s:Header>
<a:Action s:mustUnderstand="1">http://tempuri.org/ICreditCard/GetCreditCardAmount</a:Action>
<a:MessageID>urn:uuid:c7e1cd17-cec4-43ba-a203-39d11ae37125</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
</s:Header>
<s:Body>
<GetCreditCardAmount xmlns="http://tempuri.org/">
<creditCardNumber>12345678910</creditCardNumber>
</GetCreditCardAmount>
</s:Body>
</s:Envelope>

Listarea 2.2 Exemplu mesaj SOAP de tip cerere


<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://tempuri.org/ICreditCard/GetCreditCardAmountResponse
</a:Action>
<a:RelatesTo>urn:uuid:e5434dfe-96c5-4398-b6c8-d2e27a50c813</a:RelatesTo>
</s:Header>
<s:Body>
<GetCreditCardAmountResponse xmlns="http://tempuri.org/">
<GetCreditCardAmountResult>550.00</GetCreditCardAmountResult>
</GetCreditCardAmountResponse>
</s:Body>
</s:Envelope>

Listarea 2.3 Exemplu mesaj SOAP de tip raspuns


Cele dou exemple anterioare reprezint cererea, respectiv rspunsul serviciului la invocarea
operaiei GetCreditCardAmount expus de interfaa contractului, ICreditCard.
Valoarea atributului mustUnderstand = 1 (True) indic faptul c receptorul mesajului SOAP
trebuie s neleag semantica antetului din mesaj i s-l proceseze corect. Elementul
<RelatesTo> conine identificatorul unui mesaj la care acest mesaj SOAP se refer. n corpul
mesajului SOAP se gsete parametrul operaiei contractului, creditCardNumber, pentru mesajul
de tip cerere, respectiv rezultatul cererii ctre operaia serviciului n cazul mesajului de tip
rspuns.

O serie de specificaii cu privire la protocolul SOAP se gsesc la [215], [252], [254].

4)

Standardul WSDL

Web Services Description Language (WSDL) este un format XML pentru descrierea de servicii
web ca un set de endpoint uri, opernd pe mesaje care conin informaii fie orientate pe
documente, fie orientate pe proceduri [208]. Operaiile i mesajele sunt descrise abstract i apoi
sunt legate la un protocol concret de reea i format de mesaje pentru a defini un endpoint. WSDL
ul este echivalentul IDL ului (Interface Description Language), bazat pe XML, din CORBA
(Common Object Request Broker Architecture) sau COM (Component Object Model).
WSDL a ajuns la versiunea 2.0, iar n versiunea 1.1 D era acronimul de la Definition, i nu
Description aa cum este n versiunea 2.0. Versiunea 1.2 de WSDL a fost redenumit 2.0 din
cauza diferenelor majore dintre cele dou versiuni [208].
O interfa WSDL const din dou componente, aa cum este ilustrat n figura 2.6:
O parte abstract (definirea interfeei serviciului Web) descrie operaiile suportate de
serviciul web i tipurile de mesaje care parametrizeaz aceste operaii.
O parte concret (implementarea serviciului Web) descrie modul n care operaiile din
partea abstract se leag de un endpoint i modul n care mesajele se mapeaz pe
protocoalele de transport pe care endpoint urile le suport.

Figura 2.6 Structura informaiilor din WSDL (prelucrare dup [245])

Elementele componente ale unui document WSDL sunt urmtoarele:


Port/Endpoint definete adresa i modul n care se realizeaz conexiunea la un serviciu
Web. De obicei adresa aceasta este reprezentat de un URL simplu.
Serviciu const dintr-un set de porturi/endpoint-uri, n sensul c operaiile serviciului
sunt legate la protocoalele Web.
Legturi definete un format concret de mesaj i protocol de transmisie care pot fi
folosite la definirea unui port/endpoint.
Tip port/Interfa definete un serviciu Web, toate operaiile care pot fi efectuate i
mesajele folosite la efectuarea operaiilor.
Mesaje descrie parametrii de intrare i de ieire ale unei operaii, precum i valorile
returnate de operaie.
Tipuri descriu tipurile de date folosite care sunt relevante la schimbarea mesajelor.
Pentru a nelege aceste concepte am generat cu ajutorul uneltei Microsoft, disco.exe, un exemplu
WSDL (WSDL 1.1), exemplu care este n strns legtur cu exemplele anterioare de la
protocolul SOAP i standardul XML.

<?xml version="1.0" encoding="utf-8"?>


<wsdl:definitions xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
name="CreditCardService"
targetNamespace="http://tempuri.org/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:import namespace="http://schemas.microsoft.com/ws/2008/09"
location="http://sdumitra/ccService/CreditCardService/?wsdl=wsdl0" />
<wsdl:types>
<xsd:schema ...>
...
</xsd:schema>
</wsdl:types>
<wsdl:message name="GetCreditCardAmountRequest">
<wsdl:part name="creditCardNumber"
type="xsd:string" />
</wsdl:message>
<wsdl:message name="GetCreditCardAmountResponse">
<wsdl:part name="GetCreditCardAmountResponse"
type="xsd:decimal" />
</wsdl:message>
<wsdl:portType name="GetCreditCardAmountPortType">
<wsdl:operation name="GetCreditCardAmount">
Listarea 2.4 />
Exemplu document WSDL
<wsdl:input message="GetCreditCardAmountRequest"
<wsdl:output message="GetCreditCardAmountResponse" />
</wsdl:operation>
</wsdl:portType>
name="WSHttpBinding_ICreditCard"
type=" GetCreditCardAmountPortType">
n <wsdl:binding
exemplul anterior,
listarea 2.4, am generat
WSDL ul serviciului CrediCardService. n cadrul
<wsp:PolicyReference URI="#WSHttpBinding_ICreditCard_policy" />
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
elementului
<wsdl:portType>
este
definit
operaia
contractului
ICreditCard,
<wsdl:operation name="GetCreditCardAmount">
<soap12:operation soapAction="http://schemas.microsoft.com/ws/2008/09/ICreditCard/GetCreditCardAmount" style="document" />
GetCreditCardAmount
care la rndul ei conine dou mesaje, unul de intrare
<wsdl:input>
<wsp:PolicyReference URI="#WSHttpBinding_ICreditCard_GetCreditCardAmount_Input_policy" />
<soap12:body use="literal" />
GetCreditCardAmountRequest,
n care este redat semntura operaiei din punct de vedere al
</wsdl:input>
<wsdl:output>
parametrilor
de intrare i unul de ieire, GetCreditCardAmountResponse, n care este redat tipul
<wsp:PolicyReference URI="#WSHttpBinding_ICreditCard_GetCreditCardAmount_output_policy" />
<soap12:body use="literal" />
rezultatului
returnat de operaia contractului. n cadrul elementului <wsdl:service> este redat
</wsdl:output>
</wsdl:operation>
adresa
endpoint ului (atributul Address), referina ctre legtura serviciului (valoarea atributului
</wsdl:binding>
<wsdl:service name="CreditCardService">
<wsdl:port
binding="tns:WSHttpBinding_ICreditCard">
binding
dinname="WSHttpBinding_ICreditCard"
cadrul elementului <wsdl:port>)
i identitatea care trebuie prezentat la invocarea
<soap12:address location="http://sdumitra/ccService/CreditCardService/" />
<wsa10:EndpointReference>
opera
iilor serviciului (elementul <identity>).
<wsa10:Address> http://sdumitra/ccService/CreditCardService/</wsa10:Address>
<Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<Dns>sdumitra</Dns>
</Identity>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
Universal
Description, Discovery and Integration (UDDI) reprezint un framework independent
</wsdl:definitions>

5)

Standardul UDDI

de platform sub forma de repository (registru) unde pot fi nregistrate i unde se pot cuta
servicii Web, precum i descrierile pe care acestea le furnizeaz [18], [202]. Ca i celelalte

standarde din arhitectura serviciilor Web, UDDI are la baza o serie de standarde/protocoale:
HTTP, XML, XML Schema si SOAP.
UDDI este un registru care conine date i metadate ale serviciilor Web, incluznd locaia
serviciilor i informaii despre modul n care sunt invocate serviciile Web nregistrate. El este
reprezentat n cutia Registru, n cadrul figurii 2.2, din triunghiul SOA. UDDI folosete pattern
ul discovery-find-use.
Caracteristicile UDDI sunt urmtoarele:
Stocheaz informaii referitoare la serviciile Web, const din interfee ale serviciilor Web
descrise n WSDL;
UDDI poate fi interogat prin intermediul mesajelor SOAP i ofer acces la documentele
WSDL descriind anumite formate de mesaj i legturi cu protocoale de transport pentru
interaciunea cu serviciile Web.
Aceast seciune ncheie informaiile fundamentale ale serviciilor Web. n urmtoarea seciune
vom descrie, pe scurt, cerinele fundamentale i standardele de securitate ale serviciilor Web care
trebuie luate serios n considerare atunci cnd se dorete construirea de servicii Web securizate.

2.2.2. Cerine fundamentale de securitate a serviciilor Web


O soluie robust care s asigur protecia serviciilor web trebuie s aib n vedere
urmtoarele cerine fundamentale de securitate [18], [72], [155], [179]:
Identificarea procedura de stabilire a unei identiti unice pentru un utilizator sau o
entitate n cadrul unui sistem.
Disponibilitatea presupune returnarea cu promptitudine la destinatar, asigurndu-se
astfel c utilizatorii legitimi primesc serviciile la care au dreptul (datele sunt accesibile i
serviciile operaionale).
Autentificarea are rolul de a stabili identitatea uneia dintre prile implicate n
comunicare/tranzacie. Rolul primar al unui serviciu de autentificare este de a stabili
identitatea clientului sau a serverului [NIST800-12, NIST800-63]. Cnd apelul se face
direct de ctre o aplicaie client, atunci autentificarea la serviciu se poate face pe baza de
user i parol stocate ntr-o anumit surs (ex. baz de date). Dac apelul provine de la un
serviciu din cadrul aceleiai organizaii, serviciul solicitat poate fi ntr-o relaie de
ncredere cu serviciul solicitant i poate folosi autentificarea acestuia, n caz contrar se

poate efectua o re-autentificare. Exist situaii cnd cererile de autentificare/autorizare vin


de la utilizatori aflai n domenii diferite fa de domeniul serviciului, ntre aceste domenii
existnd o relaie de ncredere. n aceast situaie este nevoie de un proces de autentificare
comun. Acest scenariu este rezolvat folosind standardul SAML [18], [192], [200]. Un
mare avantaj oferit de SAML este legat de rezolvarea SSO ului (single-sign-on).
Standardul SAML va fi descris pe scurt n seciunea urmtoare.
Rezolvarea autentificrii serviciului se face folosind diverse mecanisme: criptarea,
protocoale de securitate la nivelul transport, cum ar fi SSL (Secure Sockets Layer),
protocol Kerberos, certificate X.509 sau STS (Secure Token Service). Autentificarea
trebuie s includ i posibilitatea anonimitii, deoarece nu toate serviciile au nevoie de
identitatea utilizatorilor, ci doar de confirmarea sigur pe anumite criterii (aa numitele
credite de anonimitate), cum ar fi posibilitatea de plat.
Autorizarea stabilete care sunt drepturile de acces pentru o entitate dup ce
autentificarea entitii respective a fost fcut cu succes. Deci autorizarea atribuie
autentificarea cu succes, stabilind un set de privilegii i permisii pentru entitatea
autentificat la serviciu. De exemplu, la nivelul de sistem de operare, privilegiile includ:
logarea; crearea, citirea, actualizarea i tergerea de fiiere i execuia de procese.

La

nivel de server Web, aplicaii server sau servere de baze de date privilegiile se pot rezuma
la accesarea sau actualizarea unor pagini Web, accesarea anumitor COM - uri, producerea
(rularea) unor interogri sau rapoarte.
Unul dintre cele mai comune modele de acces este Role Based Access Control (RBAC)
[98], n care rolurile acord permisiuni de a efectua aciuni asupra resurselor. n general,
utilizatorii i rolurile asociate sunt gestionate de ctre un serviciu central denumit furnizor
de identitate (identity provider IP) / manager. IP ul furnizeaz rolurile i permisiunile
de acces sub forma unui token de securitate, care mpreuna cu setul utilizator/parola sau
un certificat X.509 poate rezolva problema de autentificare anterioar, via SAML [72].
Un aspect foarte important este legat de integritatea token ului de securitate nainte s
fie efectuate decizii de autorizare.
Confidenialitatea interzice accesul neautorizat al persoanelor la informaia care nu le
este destinat. De exemplu, obiectivul acestei protecii l constituie prevenirea
monitorizrii i nregistrrii neautorizate a traficului de pe liniile de comunicaii. Pentru
realizarea confidenialitii se prefer criptarea datelor i/sau utilizarea unor protocoale de

securiatate la nivelul transport SSL/TLS [16], [18], [65]. Securitatea la nivel transport
ofer criptare doar punct la punct, ceea ce duce la anumite dezavantaje, datele putnd
fi citite/manipulate de serviciile intermediare. Pentru rezolvarea acestor probleme se
folosete securitatea la nivel mesaj care ofer criptare cap la cap, astfel nct numai
destinatarul poate citi/manipula datele cerute. Standardele care asigur securitatea la nivel
mesaj sunt XML Encryption [210] i XML Signature [213], acestea fiind descrise n
seciunea urmtoare.
Integritatea furnizeaz sigurana c datele nu au fost alterate ntr-o manier neautorizat
ct timp au fost stocate, procesate sau aflate n tranzit n reea. Cu alte cuvinte, datele
trebuie s coincid cu cele emise la origine.
Non-repudierea sau mpiedicarea nerecunoaterii tranzaciei de ctre expeditor,
garanteaz integritatea i originea tranzaciilor din punct de vedere al expeditorului, nu al
destinatarului. n acest caz, expeditorul unei tranzacii nu poate nega efectuarea acesteia.
La recepie, se poate verifica c tranzacia nu a fost alterat, inclusiv de ctre emitentul
su autentic. O utilizare foarte important a acestui serviciu este n comer ul electronic.
Cel mai folosit mecanism, n acest caz, este semntura digital (XML Signature).
Un rol important pentru verificarea integritii datelor i asigurarea non-repudierii
acestora l joac protocoalele SSL/TLS, dar apare problema asigurrii criptrii doar punct
la punct i nu cap la cap.
Protecia mpotriva atacurilor aplicaiile disponibile n Internet sunt adesea inta

atacurilor care vizeaz vulnerabilitile comune: codul nesigur (nu se face validare la
intrare), administrare srac (parole slabe), sistemele de operare i infrastructuri de reea
(implementrile TCP/IP) care au propriile defecte specifice. Cele mai folosite tehnici de a
acoperi astfel de vulnerabiliti sunt: folosirea firewall-urilor, izolarea aplicaiilor interne
de exterior, auditarea, folosirea sistemelor pentru detectarea intruziunilor (IDS).
ns serviciile Web sunt expuse public, comunicaia dintre servicii i aplicaii fcndu-se
via SOAP peste protocoalele HTTP/HTTPS, FTP, SMTP, astfel c folosirea de firewalluri nu este soluia potrivit. Cele mai multe atacuri vizeaz mesajele SOAP, iar folosirea
firewall-urilor XML reprezint o soluie n acest caz [84].
Auditul toate tranzaciile sunt nregistrate, astfel nct problemele s poat fi analizate
dup fapt.

Ameninrile cu privire la serviciile Web implic ameninri ale sistemului gazd,


a aplicaiilor i a infrastructurii din ntreaga reea. Pentru a asigura securitatea serviciilor web,
sunt necesare o serie de mecanisme de securizare pentru a rezolva probleme legate de
autentificare, controlul accesului la date, aplicarea unei politici de securitate, protecia
mesajelor. O serie de standarde pentru securizarea serviciilor Web care vor fi prezentate n
seciunea urmtoare ofer soluii pentru rezolvarea unor astfel de probleme.

2.2.3. Standarde de securitate a serviciilor Web


Standardele fundamentale ale serviciilor Web nu au ca obiectiv asigurarea securitii
acestora, deoarece ele au fost concepute doar pentru a oferi conectivitate, ceea ce poate afecta
considerabil securitatea sistemelor n care sunt integrate. Mai multe organizaii 5 au contribuit la
realizarea unor standarde pentru securitatea serviciilor Web, dar care nu ofer neaprat i
interoperabilitate [18]. O soluie n acest sens este folosirea profilului de securitate WS-I6 Basic
Security Profile [117]. n tabelul 2.1 de mai jos sunt asociate standardele de securitate cu
cerinele fundamentale de securitate.
Tabelul 2.1 Cerinte fundamentale de securitate si standarde asociate
Cerinta fundamentala de securitate
Autentificare

Standarde pentru securitate


OASIS WS-Security, OASIS WS-Trust, OASIS SAML,
OASIS WS-SecureConversation, WS-Federation, W3C XML

Autorizare
Confidentialitate
Integritate
Non Repudiere

Key Management Specification (XKMS)


OASIS XACML, OASIS SAML, WS-Security
W3C XML Encryption, WS-Security
W3C XML Signature, WS-Security
W3C XML Signature, WS-Security

Dup cum se poate observa, standardul WS-Security (WSS) este asociat la toate cerinele
fundamentale de securitate. Motivul este c acesta specific extensii ale SOAP ului care permit
criptarea sau semnarea total/parial a mesajelor SOAP. Standardul folosit la asigurarea

Dintre acestea se numara: IBM, VeriSign, W3C, OASIS, Microsoft, BEA Systems, BMC Software, CA Inc., Novell,
Layer 7 Technologies
6
WS-I este o organizatie de tip open industry care promoveaza cele mai bune practici pentru interoperabilitatea
serviciilor Web. Aceste practici creeaza profile si suport pentru unelte de testare ale standardelor serviciilor Web. Mai
multe informatii se pot gasi la http://www.ws-i.org.

confidenialitii mesajelor este XML Encryption, n timp ce standardul XML Signature este
folosit la asigurarea integritii mesajelor.

1)

Semnatura XML

Semntura XML (Eastlake, Reagle i Solo, 2002), realizat la propunerea W3C si IETF,
reprezint o semntur digital proiectat pentru a fi utilizat n tranzaciile XML. Semntura
XML combin utilitatea i puterea tehnologiei semnturii digitale, cu puterea i flexibilitatea
XML-ului [18], [180], [213]. La fel ca i n cazurile semnturilor non-XML (ex. PKCS),
"semnturile XML adaug informaii de autentificare, integritate i nerepudiere a datelor pe care
le semneaz" [155].
Semntura XML specific modul de reprezentare a semnturii digitale ca i un element XML,
precum i modul de creare i verificare ale acestui element XML. Ea se aplic att datelor de tip
XML, ct i datelor de tip non-XML. O caracteristic important a semnturii XML se refer la
posibilitatea de a semna un ntreg document XML, anumite poriuni dintr-un document XML
(elemente XML XML tree) sau fiiere care conin orice tipuri de date digitale. Semntura XML
permite semnarea mai multor date cu o singur semntur.
Atunci cnd semntura XML este folosit independent, asigur integritatea datelor, iar cnd este
legat de identitatea semnatarului, ea furnizeaz non-repudierea coninutului datelor i,
de asemenea, poate furniza autentificarea semnatarului.
n listarea 2.5, de mai jos, am redat un exemplu simplu de semntur XML.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>togXNC4OzEdceUMpTPlvuCi0GC4=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
Rjad941bAcFFTMb5i1m2A17jZx/luVZobea9Rjhs0mbHE5xRP7RnPSfT///hdhBnzAmrl6+zrWaPOuNsZVM2jMsahk5vBxugd9bzfp
OXK3MuVjeJUSCvL1JxVrCpqd2vdfYbxIZIrY1ZnQyzZxRCO7Q5AcuODc4sxHGlVCC13m9XFa2jW2fKOGJlE3JJX6z9U2ymlmzq
saV6MP8hCsDFiFZhbJhQSeqg2vZMduvNtSP6I+yqfbc49OvLS3Ub5qWoSV1r19wa79WTpPJi3ub1xrBR6r6Wt4ZE+QOFAooP8c
9mw6O6ApRCn2U6I5FmclxuXAy9s0akReqERgWGYTs/6Q==
</SignatureValue>
</Signature>

Listarea 2.5 Exemplu semntur XML

Semnificaia elementelor din cadrul semnturii XML este urmtoarea:


Signature este rdcina semnturii XML. Semntura XML este format din patru blocuri
principale, aa cum arat elementul sau rdcina <!ELEMENT Signature (SignedInfo,
SignatureValue, KeyInfo?, Object*>.
SignedInfo conine informaia care se semneaz i a crei valoare final se stocheaz n
elementul SignedValue. CanonicalizationMethod (codificare) specific algoritmul folosit
la canonizarea (pregtirea) elementului SignedInfo nainte ca acestuia s i se aplice o
funcie hash ca parte a operaiei de semnare. SignatureMethod specific algoritmul folosit
la convertirea elementului canonizat SignedInfo n elementul SignatureValue, adic la
semnarea amprentei numerice a SignedInfo. Acest algoritm identific toate funciile
criptografice implicate n procesul de semnare, de exemplu, funcii hash, algoritmi cu chei
publice, MAC uri, algoritmi de padding .a.m.d.. Fiecare element Reference conine
algoritmul de hash folosit i valoarea hash a obiectului transformat. De asemenea, poate
conine o list a transformrilor produse de operaia de semnare.
SignedValue conine valoarea semnturii efectuate pe SignedInfo, obinut conform
directivelor de calcul indicate n KeyInfo.
KeyInfo conine toi parametrii necesari verificrii semnturii. Este un element opional,
deoarece toate datele pot fi cunoscute din aplicaie.
ntr-o semntur XML numai datele semnate sunt sigure. De aceea trebuie s se fac o distincie
clar ntre datele semnate i cele care nu sunt semnate. Semnturile XML trebuie s fie rezistente
mpotriva substituirii, adic modificarea datelor care nu particip la procesul de semnare s nu
afecteze verificarea semnturii.
Securitatea semnturii XML trebuie s aib n vedere o serie de aspecte referitoare la securitatea
schemelor de semntur digital i a funciilor hash criptografice. Aceste aspecte sunt tratate n
seciunea funciilor hash i a semnturilor digitale.

2)

Criptarea XML

Criptarea XML (Imamura, Dillaway, & Simon, 2002), realizat la propunerea W3C, reprezint un
proces pentru criptarea datelor i reprezentarea rezultatului n format XML [210].

Datele care urmeaz a fi criptate pot fi date arbitrare, cum ar fi: un document XML, un element
XML sau coninutul unui element XML. Rezultatul criptrii datelor este un element de criptare
XML care conine sau face referire la datele criptate.
Criptarea XML nu este un algoritm nou de criptare, ci o modalitate de a cripta elemente XML.
Rolul principal al criptrii XML este asigurarea confidentialitatii datelor, adic interzice accesul
neautorizat al persoanelor la informaia care nu le este destinat. n cadrul criptrii XML datele
sunt transformate n octei serializai pentru operaii de criptare i decriptare.
Dup cum am prezentat anterior, protocoalele SSL/TLS asigur criptare punct la punct, ns
acest lucru nu este suficient pentru protejarea coninutului mesajelor de atacurile de tip
eavesdropping (la noduri intermediare). Criptarea XML este o soluie pentru securitatea cap la
cap, furniznd criptare persistent.
Informaii cu privire la criptarea XML pe platforma .NET se gsesc la [128]. Criptarea XML are
o aplicabilitate major n procesul de criptare a mesajelor SOAP. De aceea, ea face parte din
standardul WS-Security. Criptarea XML poate fi aplicat att n criptarea antetului mesajului
SOAP, folosind algoritmi de criptare cu chei publice, ct i n criptarea corpului mesajului SOAP,
folosind algoritmi de criptare cu chei simetrice.
Un exemplu se criptare XML este redat n listarea 2.6 de mai jos:
<e:EncryptedData Id="EncData" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk" />
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>+C28OaBM4/VIpxH9jcjofix/1/</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
<e:EncryptedKey Id="EncKey">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
....
</KeyInfo>
<e:CipherData>
<e:CipherValue>+lpzTxYarAE45BUdrOCsh2vheLw</e:CipherValue>
</e:CipherData>
<ReferenceList>
<DataReference URI="#EncData" />
</ReferenceList>
</e:EncryptedData>

Listarea 2.6 Exemplu criptare XML


Semnificaia elementelor din listarea de mai sus este urmtoarea [134]:

EncryptedData este elementul rdcin al datelor criptate;


EncryptionMethod este un element opional i este folosit pentru a specifica algoritmul

de criptare simetric folosit, sub forma unui URI, pentru criptarea datelor (tripledes-cbc,
aes128-cbc, aes192-cbc, aes256-cbc etc.);
KeyInfo este elementul care furnizeaz informaii cu privire la cheia secret. Are aceeai
sintax ca i n cazul XML Signature. Informaiile cu privire la cheia de criptare folosit
sunt necesare pentru decriptarea la destinatar;
CipherData este un element obligatoriu care furnizeaz informaii cu privire la datele
criptate. n CipherData se gsesc fie datele criptate (codificarea Base64 a elementului
CipherValue), fie o referin extern la datele criptate furnizat de elementul
CipherReference;
CipherValue este un element obligatoriu i conine datele criptate;
EncryptedKey conine cheia de criptare criptat care este folosit n blocul
EncryptedData. Este folosit la criptarea simetric a mesajului (parial sau total) i este
criptat cu cheia public a destinatarului. Elementul conine toate informaiile necesare
pentru decriptarea cheii simetrice la destinatar, mpreun cu o serie de elemente care au
fost criptate cu aceast cheie. Acest element este opional n cazul n care prile au agreat
o anumit cheie.

3)

Standardul XKMS

XML Key Management Standard (XKMS) reprezint "un set de protocoale pentru distribuirea i
nregistrarea cheilor publice pentru a fi folosite n conjuncie cu standardul pentru semnturile
XML i ca standard de companie pentru criptarea XML " [211]. XKMS furnizeaz mijloace de
accesare a unei PKI de ncredere sub forma unui serviciu (interfee), permind unui client s
foloseasc funcionalitatea de gestionare complex a cheilor. Exist dou servicii specificate de
XKMS:
XML Key Information Service Specification (X-KISS) "un protocol care sprijin
delegarea printr-o cerere la un serviciu de procesare a informaiilor despre chei asociate
cu o semntur XML, criptare XML sau alt utilizare a semnturii XML" [42];
XML Key Registration Service Specification (X-KRSS) "un protocol care sprijin
nregistrarea unei perechi de chei de un titular de perechi de chei, cu intenia ca perechea
de chei s fie ulterior utilizat n conjuncie cu X-KISS sau o PKI" [211].

4)

Standardul SAML

Security Assertion Markup Language (SAML) V2.0 (Hughes & Maler, 2005), standard de
specificaii OASIS aprobat la 15 martie 2005, "este un framework bazat pe XML pentru
comunicarea informaiilor cu privire la autentificarea utilizatorului, drepturi i atribute dintre
pri de ncredere sub form de aseriuni" [192]. SAML V1.0 a devenit standard OASIS n
noiembrie 2002, versiunea V1.1 a fost aprobat ca i standard n septembrie 2003, iar SAML
V2.0 a fost aprobat n martie 2005. n prezent este n plan pentru aprobare versiunea SAML 2.1
[200]. Aseriunile SAML sunt unele dintre blocurile de baz ale standardelor de securitate ale
mesajelor SOAP, precum i ale standardelor referitoare la politicile de securitate, controlul
accesului i managementul identitilor federative. Ele afirm identitatea i autorizaiile de acces
ale unui subiect i pot fi folosite de diferite domenii de ncredere pentru a acorda acces la resurse
pentru acest subiect. Acest proces stabilete o identitate comun ntre domenii diferite i se
numete federaie de identiti (identity federation).
SAML ul suport trei tipuri de aseriuni [188]:
Atribut precizeaz c un subiect S este asociat cu un set de atribute

cu valori

De

exemplu, subiectul Stelian este asociat cu atributul "Universitate" cu valoarea "Academia


de Studii Economice";
Autentificare precizeaz c un subiect S a fost autentificat de entitatea M la un anumit
timp. Aceast aseriune este furnizat de entitatea care autentific cu succes subiectul. De
exemplu, o astfel de aseriune precizeaz urmtoarea afirmaie: "Stelian a fost autentificat
cu succes folosind un mecanism pe baz de parol la data de 01-06-2015T 20:20:30";
Autorizare precizeaz care sunt aciunile permise de subiectul S asupra unei resurse R
(de exemplu dac un utilizator S este autorizat s foloseasc un serviciu web).
Conform versiunii V2.0, standardul SAML are patru componente [192]. n figura 2.7 sunt
redate aceste componente i legturile dintre ele.

Figura 2.7 Componentele SAML


Profilul "web browser SSO" este cel mai relevant dintre profiluri, el permind scenarii n care un
utilizator care folosete web ul, fie acceseaz resursele de la un serviciu furnizor, fie acceseaz
un furnizor de identitate pentru autentificare [190]. Furnizorul de identitate genereaz aseriuni
care pot fi validate de serviciul furnizor i folosite la stabilirea unui context de securitate pentru
utilizator, context ce poate conine permisiunile pentru accesul la resursele dorite (pot fi sub
forma de claim - uri). Acest scenariu este ilustrat n figura 2.8.

Figura 2.8 Mecanismul conceptului SSO


Aseriunile SAML pot fi folosite n cadrul mesajelor SOAP cu scopul de a transporta informa ii
de securitate i identitate ntre ageni web. Profilul SAML Token Profile al OASIS WS-Security TC
specific modul n care aseriunile SAML pot fi folosite n acest scop. Liberty Alliance folosete

framework ul Identity Web Service Framework (ID-WSF) cu scopul de a folosi aseriuni


SAML sub forma de token uri de securitate pentru accesul securizat la serviciile Web [186].
Microsoft ofer Windows CardSpace [201] i Windows Identity Foundation (WIF) [232] n
acest scop.
n listarea 2.7 de mai jos am redat un exemplu simplu de aseriune SAML, de autentificare pe
baz de parol.
Elementul Conditions [1] specific dou condiii pentru aseriune. Intervalul de timp dintre
valorile atributelor NotBefore i NotOnOrAfter specific perioada de validitate a aseriunii.
Elementul AuthenticationStatement [2] conine dou atribute i un element copil. Primul atribut
AuthenticationMehod specific metoda de autentificare a aseriunii folosit.
Singurul element copil Subject conine informaii despre subiectul autentificat: NameIdentifier
conine numele subiectului i SubjectConfirmation conine relaia dintre subiectul aseriunii i
autorul aseriunii.
Elementul ConfirmationMethod [2b1] este un copil al elementului SubjectConfirmation [2b].
Exist dou profiluri SSO folosite pentru elementul SubjectConfirmation: Browser/Artifact
<saml:Assertion

Profile ixmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
Browser/POST Profile, ambele cu rol n autentificarea i autorizarea subiectului.

[1]

[2]

[2a]
[2a1]
[2a1a]
[2a1b]
[2a1c]
[2b]
[2b1]
[2b1a]

[3]

MajorVersion="1"
MinorVersion="1"
AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
Issuer="www.acompany.com"
IssueInstant="2015-06-30T20:20:00.490Z">
<saml:Conditions>
NotBefore="2015-06-30T20:15:00.490Z"
NotOnOrAfter="2015-06-30T20:45:50.490Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="password"
AuthenticationInstant="2015-06-30T20:20:00.490Z">
<saml:Subject>
<saml:NameIdentifier
NameQualifier=http://www.endava.com
Format=http://www.endavaformat.com/>
uid=sdumitra
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
</saml:ConfirmationMethod>
<ds:KeyInfo>
<ds:KeyName>keyLogin</ds:KeyName>
<ds:KeyValue>
3eG9OCiKJsxA5PZV2ohmSCdtUScsJOXmrgBrIaMgHJlBDb
Fp
</ds:KeyValue>
</ds:KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
<ds:Signature>
5hEB8rxKJqgxo8HRb4bEejPzQerCQ0oteT85w5TMz/96FDrPkKmwvWp2mCsgZRpY/8kcSp/
tpPMvB7San6/XTOfUhXKkxirP+2gLJ91bt+skp5E8c83rYoUofIvhLVIzChlirBF39WlJx
vikibzwcFOAzrvC+p4Kff6EAf/bC2KpNq0Jgti0xK3nw5sXceJPKMK9Cc5dypCKt7oJk
</ds:Signature>
</saml:Assertion>

Listarea 2.7 Aseriune SAML de autentificare pe baz de parol

5)

Standardul XACML

eXtensible Access Control Markup Language (XAML) este o specificaie pentru reprezentarea
politicilor de autorizare i afirmare. OASIS l definete ca fiind "un limbaj bazat pe XML pentru
controlul accesului" [189]. Standardul descrie dou limbaje [189]:
Limbaj pentru politicile de control al accesului "este folosit pentru a exprima politicile
de control al accesului ("cine poate face ce cnd")";
Limbaj Cerere/Rspuns "exprim interogri despre un anumit acces dac ar trebui s
fie permis (cereri) i descrie rspunsurile la aceste interogri (rspunsuri)" . Cererile de
acces sunt gestionate de un Policy Enforcement Point (PEP). Un Policy Decision Point
(PDP) este contactat pentru a verifica dac cererea este permis nainte de a acorda
accesul la servicii.

6)

Standardul WS-Security

n aprilie 20027, IBM i Microsoft au propus un model de securitate, ilustrat n figura 2.9, pentru
dezvoltarea unui set de standarde de securitate al serviciilor web pentru protejarea mesajelor
SOAP schimbate prin intermediul serviciilor web [197].
Modelul de securitate include tehnologii de securitate cum ar fi: infrastructuri cu chei publice,
protocol Kerberos, criptri etc.. Standardele incluse n model trebuia s ofere suport pentru
mecanismele de securitate: autentificarea, autorizarea, privilegierea, ncrederea, integritatea,
confidenialitatea, comunicaiile securizate i auditul.
Standardul WS-Security a fost aprobat ca i standard OASIS n anul 2002 [197].

Lucrarea intitulat Security in a Web Service World, A Proposed Architecture

Figura 2.9 Modelul de securitate al serviciilor web (prelucrare dupa [134])


Trei mecanisme principale sunt definite de standard: "abilitatea de a trimite token uri de
securitate ca parte a unui mesaj, integritatea mesajului i confidenialitatea mesajului" .
Integritatea mesajului este furnizat de semntura XML, n timp de confidenialitatea este
asigurat de criptarea XML; ambele pot fi folosite n conjuncie cu token uri de securitate.
Un token de securitate este o colecie de claim uri, unde un claim reprezint o afirmaie despre
o entitate (ex. nume, identitate, privilegiu, e-mail, cheie, capabilitate). Standardul WS-Security
este neutru la tipul de token folosit. Astfel, el suport o serie de formate de token-uri:
username/password, aseriuni SAML [200], tichete XrML/REL [196], certificate X.509 [194],
tichete Kerberos [195]. Pentru token urile pe baz de certificate X.509 i tichete Kerberos, care
nu sunt codificate n format XML, standardul WS-Security furnizeaz mecanisme pentru
<S:Envelope>
codificarea
<S:Header> binar a acestora.
<wsse:Security>

n listarea
2.8 am reprezentat includerea unei semnturi XML n antetul unui mesaj SOAP.
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
wsu:Id="X509Token">
FIgEZzCRF1EgILBAgIQEmtJZc0rqrKh5i...
</wsse:BinarySecurityToken>
<ds:Signature>
<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="#body">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>EULddytSo1...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
XLdER8=ErToEb1l/vXcMZNNjPOV...
</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#X509Token"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body wsu:Id="body">
<xenc:EncryptedData Id="body">
...
</ xenc:EncryptedData>
</S:Body>
</S:Envelope>

Listarea 2.8 Includerea unei semnturi XML n antetul unui mesaj SOAP
Dup cum se poate observa, elementele cu namespece ul wsse reprezint extensii ale SOAP
ului definite de WS-Security. Elementul <BinarySecurityToken> identific cheia public dintr-un
certificat X.509 care este folosit la verificarea semnturii. Elementul <SecurityTokenReference>
pointeaz la token ul de care este legat semntura, care la rndul ei refereniaz elementul
<Body>.

7)

Standardele WS-Policy, WS-Policy Assertion, WS-Policy Attachment si WSSecurity Policy

Standardul WS-Policy definete politica cerinelor de securitate pentru serviciile Web, descriind
diferite constrngeri (politici) de securitate cu privire la intermediari i endpoint uri (token uri
de securitate necesare, algoritmi de criptare folosii, roluri privilegiate etc.). WS-Policy Assertion
specific aseriuni de securitate generice. WS-Policy Attachment i WS-Security Policy ofer
mecanisme pentru a reprezenta capabilitile i cerinele mesajelor SOAP ca i politici [209].

8)

Standardul WS-Trust

Scopul acestei specificaii este de a permite aplicaiilor s participe la schimbul de mesaje SOAP
de ncredere. Standardul definete extensii care se bazeaz pe WS-Security i se folosesc pentru
cererea, emiterea, rennoirea i validarea token urilor de securitate, precum i la gestionarea
relaiilor de ncredere dintre acestea [199].
Un Security Token Service (STS) este un serviciu web responsabil pentru emiterea de token uri
de securitate i poate fi vzut ca un broker de ncredere [199]. Cnd un solicitant de serviciu,
dintr-un domeniu diferit de ncredere (posibil necunoscut), are nevoie de un token de securitate pe
care trebuie s-l prezinte serviciului furnizor l poate obine fcnd o cerere ctre STS.

cazul n care token ul a fost emis de ctre STS, solicitantul de serviciu prezint acest token

serviciului furnizor, acesta din urm fiind cel care valideaz token ul. Pentru a valida token ul,
ntre STS i serviciul furnizor trebuie s existe o relaie de ncredere.

9)

Standardul WS-SecureConversation

Standardul WS-SecureConversation este construit deasupra standardelor WS-Trust i WSSecurity i furnizeaz mecanisme pentru stabilirea i partajarea unui context de securitate,
precum i a unei chei derivate de sesiune [198]. WS-Security se concentreaz pe autentificarea
unui singur mesaj SOAP, n timp ce WS-SecureConversation este utilizat la stabilirea unui
context de securitate ntre dou pri care permite autentificarea mai multor mesaje SOAP i
mbuntete performana de comunicare. Un alt avantaj l reprezint negocierea cheii (lor) de
sesiune, derivat (e) dintr-o cheie secret partajat asociat cu contextul de securitate, cheie (i) de
sesiune folosit (e) la criptarea/decriptarea i semnarea/verificarea n contextul securizat.

10)

Standardul WS-Federation

Aceast specificaie a fost definit de cteva organizaii, iar n momentul de fa este standard
OASIS [187]. WS-Federation este un framework construit pe baza specificaiilor WS - *, cum ar
fi WS-Security, WS-Trust, cu scopul de a oferi un mecanism extensibil de federa ie, un concept
deja menionat n cadrul seciunii standardului SAML. O federaie trebuie s fie capabil s
gzduiasc diferite domenii de securitate (colecie de realms), fcnd posibil autentificarea
utilizatorilor ntr-un domeniu de securitate i folosind identitatea, atributul, autentificarea i
aseriunile de autorizare s solicite accesul la resurse dintr-un alt domeniu. Un furnizor de resurse
dintr-un domeniu de securitate poate oferi acces autorizat la o resurs pe care o gestioneaz pe
baz de claim uri ale unui principal (identitate sau atribute distincte), claim uri care sunt
afirmate de ctre un IP/STS dintr-un alt domeniu (mecanism SSO) 8. WS-Federation sugereaz c
organizaiile care particip n federaie ar trebui s publice cerinele de securitate i comunicare n
metadatele federaiei (Federation Metadata). Fiecare domeniu de securitate poate folosi diferite
token uri de securitate (ex. certificate X.509, tichete Kerberos sau aseriuni SAML).

https://msdn.microsoft.com/en-us/library/bb498017.aspx