Cuprins

Aceasta lucrare poate fi descarcata doar daca ai statut PREMIUM si are scop consultativ. Pentru a descarca aceasta lucrare trebuie sa fii utilizator inregistrat.

Extras din document

CUPRINS:

Capitolul I. Serviciile Web

1.1
Aparitia si dezvoltarea serviciilor Web
7
1.2
Serviciile Web. Notiuni generale
10

1.2.1
Metodele serviciilorWeb
12

1.2.2
Arhitectura solutiei. Suita de tehnologii (XML, UDDI, WSDL, SOAP)
14
Capitolul II. Securitatea serviciilor Web

2.1
Modelul de securitate a serviciilor Web
27

2.1.1
Principiile modelului de securitate a serviciilor Web
29

2.1.2
Specificatiile de securitate a serviiciilor Web
31

2.1.3
Comparatia modelelor de securitate a serviciilor Web
36
2.2
Securitatea serviciilor Web in ASP.NET. Modelul de securitate


2.2.1
Securitatea la nivel de platforma/transport (point-to-point)
38

2.2.2
Securitatea la nivel de aplicatie
39

2.2.3
Securitatea la nivel de mesaj (End-to-End)
41

2.2.4
Arhitectura securitatii la nivel de transport
42

2.2.5
Strategiile de autentificare si de autorizare
43

2.2.6
Configurarea securitatii
48

2.2.7
Trimiterea credentialelor pentru autentificare catre Web Service
51

2.2.8
Transferul Apelatorului Original
54

2.2.9
Utilizarea certificatelor digitale cu Web Service
55
Capitolul III. Aplicatii practice

3.1
Lucrul cu protocoalele SSL/TLS
59

3.1.1
Protocoalele SSL/TLS
59

3.1.2
Setarea serverului Web pentru lucrul cu protocoalele SSL/TLS
59

3.1.3
Generarea cererii pentru un Certificat Digital
60

3.1.4
inregistarea unei cereri pentru Certificat Digital
62

3.1.5
Emiterea Certificatului
62

3.1.6
Instalarea Certificatului pe serverul Web
63

3.1.7
Configurarea resurselor pentru cererea SSL Access
63
3.2
Folosirea protocoalelor SSL/TLS in serviciile Web
63
3.3
Apelarea Web service folosind SSL
66

3.3.1
Crearea unui Web service
66

3.3.2
Configurarea directorului virtual a serviciului Web pentru utilizarea SSL
69

3.3.3
Testarea serviciului Web folosind browser-ul
70

3.3.4
Instalarea certificatului pe calculatorul client
71

3.3.5
Dezvoltarea aplicatiei Web pentru apelarea serviciului Web
72
3.4
Apelarea unui serviciu Web folosind certificatele client
74

3.4.1
Crearea unui Web Service
76

3.4.2
Configurarea directorului virtual a serviciului Web pentru utilizarea Certificatelor Client
79

3.4.3
Crearea unui cont Custom pentru rularea componentei deservite (Serviced Component)
80

3.4.4
Cererea Certificatului Client pentru contul Custom
80

3.4.5
Testarea Certificatului Client folosind browser-ul
82

3.4.6
Exportarea Certificatului Client catre un fisier
83

3.4.7
Dezvoltarea componentelor deservite pentru apelarea Web Service
84

3.4.8
Configurarea si instalarea Componentei Deservite
88

3.4.9
Dezvoltarea aplicatiei Web pentru apelarea componentei deservite
89
Concluzii:
91

Alte date

?

Capitolul I. Serviciile Web

1.1 Aparitia si dezvoltarea serviciilor Web

La inceput a fost TCP/IP-ul, acesta a avut o evolutie fantastica: a aparut in primele retele din anii ’70 si pana in zilele noastre a reusit sa cucereasca toata planeta. Interesant este ca suita de protocoale TCP/IP a EVOLUAT, mereu s-au adus imbunatatiri la el fara sa i se intrerupa prezenta in retele si, poate mai important, fara sa i se blocheze evolutia. Înca de la inceput, TCP/IP-ul a fost si a ramas protocol deschis, guvernat de organizatii de standardizare independente ca IETF sau W3C. Oricine putea sa aduca imbunatatiri. Bineinteles ca aceste organizatii se ocupa de multe alte standarde fara de care internetul de azi nu ar mai fi la fel. Exista unele lucruri insa, fara de care internetul nu ar exista. TCP/IP-ul este unul din ele.

Dezvoltatorii de software au fost multumiti o vreme, pana cand nu a mai fost de ajuns sa construiasca aplicatii care sa aiba drept consumator omul. Era nevoie ca aplicatiile sa comunice intre ele. Aici s-a produs ruptura. Între marile companii furnizoare de tehnologie nu a mai fost acelasi consens la problemele de comunicatie intre aplicatii cum a fost odinioara la problemele de comunicatie intre calculatoare. Au fost cateva incercari dintre care s-au detasat DCOM (Distributed Component Object Model) de la Microsoft, RMI (Remote Method Invocation) de la Sun si CORBA (Common Object Request Broker Architecture) de la OMG (Object Management Group). Necazul e ca nici una din cele trei tehnologii nu a fost adoptata de toata lumea.

Era nevoie ca toti sa urmeze modelul standardelor deschise. Fiindca TCP/IP-ul a fost al nimanui si a avut succes tocmai prin caracterul deschis, trebuia gasit ceva asemanator (la nivelul aplicatiilor) care sa fie tot al nimanui si sa fie bazat pe standarde. Acel ceva este reprezentat de serviciile web. Daca lumea IT reuseste sa impuna serviciile web bazate pe standarde, s-a rezolvat problema, fiindca furnizorii de produse software vor imbratisa ideea de servicii web realizand produse care stiu sa comunice astfel cu orice alt produs indiferent de platforma pe care ruleaza, indiferent de cine le-a creat si indif+erent cu ce tehnologie le-a construit. Problema nu este atat de simpla, insa ideea este extraordinara si realizabila. În ultimii ani s-au definitivat zeci de standarde in acest domeniu si suntem in faza in care putem spune ca serviciile web vor avea succes cel putin la fel ca batranul TCP/IP. Mai mult, pentru accelerarea standardizarii si pentru oferirea unei garantii ca prin serviciile web se va asigura interoperabilitatea mult dorita, s-a creat si WS-I, un organism care furnizeaza documente mature pentru W3C si IETF.

Lumea IT a ajuns la consens in ceea ce priveste caracteristicile acelui ceva care va rezolva comunicatia intre aplicatii. Acel ceva trebuie sa fie:

? independent de masina (PC-uri, masini mari sau dispozitive mobile), de sistemul de operare, de limbajul de programare, de baza de date sau de arhitectura,

? modular,

? sa suporte comunicatie intre aplicatii slab cuplate (cu gandul la internet),

? utilizabile in orice domeniu, de la solutii simple P2P (Peer to Peer) la sisteme EAI (Enterprise Application Integration) si pana la sisteme B2B (Business to Business) de anvergura.

Toate solutiile de pana acum (DCOM, RMI sau CORBA) au probleme majore cu cel putin doua dintre cerintele de mai sus. Trebuie sa amintim aici si o solutie mai exotica numita EDI (Electronic Data Interchange), care parea sa rezolve problema.

Ca sa putem intelege de ce in mintea specialistilor in IT a aparut conceptia de web-service, prin ce ea difera de celelalte incercari de a crea tehnologii de dezvoltare a sistemelor informatice si, cel mai important, de ce e atat de buna, cum spun expertii companiilor-vendori si analistii sectorului IT, e necesar sa ne intoarcem cu cativa ani in trecut si sa privim cum se dezvoltau tehnologiile crearii sistemelor informatice, ce a fost creat si ce probleme au aparut. Cum se intimpla de obicei, in totul sunt “vinovati” banii. Cand retelele de calculatoare au iesit din cadrul organizatiilor strict militare si stiintifice(cum ar fi ARPAnet), ele au ajuns in mana particularilor. În momentul in care numarul utilizatorilor a crescut a aparut ideea ca retelele de calculatoare pot fi folosite in afaceri. Astfel, retelele de calculatoare de uz comun, principala si cea mai raspandita din care astazi se numeste Internet, au ajuns business-instrument. Dar ca sa conduci un business cu un astfel de instrument, el trebuie sa corespunda unui set de cerinte, cele mai importante dintre care sunt – securitatea si viteza de transfer a informatiei. Problema rezolvarii acestor cerinte au inceput sa o rezolve la nivelul cel mai de jos – nivelul protocoalelor de transport. Diferite companii au propus diferite realizari a protocoalelor de retea. Protocoalele de retea, dupa cum se stie, contin regulile de formare a pachetelor si schimbul dintre ele. Aplicatiile ce folosesc aceste reguli (diferite pentru diferite protocoale) sunt strins legate de aceste protocoale. Între timp relatiile B2B (Business–to–Business) cereau ca aplicatiile de retea ce foloseau protocoale diferite sa poata comunica intre ele – in asa fel a aparut problema integrarii aplicatiilor.

Pe parcursul catorva ani au fost elaborate cateva tehnologii de interactionare intre aplicatii care permiteau, intr-un fel sau altul, realizarea schimbului de date intre aplicatii (cele mai raspandite dintre care – Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) si Common Object Request Broker Architecture (CORBA)), insa fiecare dintre ele a fost destul de greu realizabila, nu dispunea de universalitate necesara (De exemplu: Toti utilizatorii trebuiau sa aiba acelasi sistem de operare) si, cel mai rau, aceste tehnologii erau greu compatibile intre ele. Aceasta situatie nu putea sa multumeasca nici business-ul, nici pe specialistii IT.

Atunci s-a apelat la web-tehnologii de baza, s-a incercat gasirea acelui putin, ce se afla la baza Internetului. Dar aceasta baza e constituita din urmatoarele tehnologii:

? TCP/IP – protocolul universal, acceptat de catre toate dispozitivele de retea, de la mainframe-uri la telefoane mobile si PDA;

? HTML – limbaj universal, folosit pentru redarea informatiei cu dispozitivele utilizatorilor;

? XML – limbaj universal pentru lucrul cu orice tip de date.

În fiecare definitie e constient subliniata universalitatea fiecarei din tehnologii, pentru ca aceasta universalitate este baza intelegerii serviciilor web. Ele sunt bazate numai pe tehnologii larg acceptate, deschise si formal independente de vendori. Doar prin intermediul acesta se ajunge la principalul avantaj al serviciilor web – universalitatea lor, adica independenta de sisteme de operare, limbaje de programare, servere de aplicatii, etc. Astfel, serviciile web rezolva problema initiala – problema integrarii aplicatiilor de natura diferita si construirea sistemelor informationale distribuite. Aceasta si este diferenta de baza dintre serviciile web si predecesorii sai. Cu ajutorul serviciilor web cateva, uneori total diferite, business-procese se pot integra intr-un singur business-proces.

Si totusi web-services nu pot fi privite ca leac de toate business-probleme. Serviciile web, ca si multe altele, au plusurile si minusurile lor si, prin urmare, domeniile de aplicare. Necunoasterea si neconformarea in aceste domenii in proiecte reale poate duce la urmari destul de grave.

Plusurile web-service sunt:

? Web-services permit companiei integrarea propriilor business-procese cu business-procese ale business-partenerilor si clientilor sai cu costuri mult mai mici, decat cu alte tehnologii. Costurile unor asemenea solutii este accesibila si IMM-urilor, ceea ce va deschide companiei noi orizonturi;

? Întrucat serviciile web se organizeaza in registri publici (UDDI, ebXML), accesibili persoanelor interesate din toata lumea, pragul iesirii companiei pe piete noi se micsoreaza, posibilitatile cresterii bazei de clienti insa, cresc.

? Serviciile web asigura compatibilitatea in relatia cu sisteme informationale deja existente in companie. Astfel, se pastreaza investitiile facute anterior si nu sunt necesare schimbari radicale.

? Construirea solutiilor noi cu aplicarea serviciilor web se realizeaza mai rapid si mai putin costisitor.

Neajunsurile serviciilor web:

? Standardele de integrare a aplicatiilor, crearea politicilor IT si business ce pot interactiona prin intermediul serviciilor web se afla inca in stadiul de continua dezvoltare si elaborare. Mai multe companii lucreaza in paralel asupra serviciilor web (Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS)) de la IBM, XLANG de la Microsoft si specificatiile WS-Coordination si WS-Transaction – rezultatul colaborarii IBM, Microsoft si BEA). Evident, fara formularea stricta a lor construirea sistemelor informatice pe baza tehnologiei web-service poate merge doar cu succes intermitent.

? Folosirea dinamica a informatiilor din registrii serviciilor web, apelul serviciilor concomitent cere rezolvarea problemelor relatiei de incredere intre diferiti registri. În plus, sunt probleme in utilizarea concomitenta a registrilor de formate diferite.

? Specificatia WS-Security – produsul colaborarii IBM si Microsoft – este destul de “tanara” si este mereu innoita. Se pregatesc deja specificatiile destinate securitatii serviciilor Web: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

Analizand cele relatate mai sus, se poate observa ca plusurile sunt de domeniul strategic, pe cand minusurile au caracter tehnic, datorita noutatii tehnologiilor serviciilor Web. Rezolvarea acestor probleme este doar problema de timp.

1.2 Serviciile Web

Definitia data de organizatia W3C este: un web-service este un sistem software identificat de URI [RFC 2396], a carui interfete publice si legaturile sunt definite si descrise folosind XML. Definirea sa poata fi gasita si de alte sisteme software. Aceste sisteme pot ulterior interactiona cu web-service in acord cu definirea sa, folosind mesaje bazate pe XML transmise cu ajutorul protocoalelor Internet.

Definition: A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

Din definitia de mai sus, observam ca unica tehnologie ce este folosita cu strictete este XML. Nu se aminteste nici de protocolul de retea folosit, nici de limbajul de programare, nici de platforma pe care se realizeaza. Unica conditie – folosirea mesajelor XML (mai precis SOAP), intrucat alternativa reala pentru XML, ca limbaj ce permite lucrul cu orice tip de date, in ziua de azi nu exista.

Web Services este o tehnologie .NET folosita pentru crearea de componente programabile. Multe aplicatii folosesc tehnologii de componente distribuite, cum ar fi Distributed Component Object Model (DCOM) si Remote Procedure Call (RPC). O problema comuna a acestor tehnologii este dependenta de platforma. Web Services foloseste tehnologii de Internet standard, cum ar fi HTTP si XML. Independenta de platforma creeaza posibilitatea si pentru sistemele eterogene de a folosi aceste aplicatii. Utilizatorii nu mai trebuie sa stie in ce limbaj a fost creata o aplicatie sau un serviciu. Nu mai trebuie sa stie decat care sunt facilitatile pe care le ofera si cum le pot utiliza in propriile lor aplicatii.

Serviciile Web prezinta un urias potential de utilizare intr-o mare varietate de aplicatii folosite in Internet, cum ar fi cele pentru serviciile meteorologice, pentru stiri bursiere, pentru serviciile de stiri, pentru serviciile de urmarire a pachetelor si pentru serviciile asociate. De exemplu, o firma care vinde carti prin Internet, cum este Amazon.com, ar putea sa includa o facilitate pentru urmarirea pachetelor folosind o componenta Web Service de la o firma de distributie prin posta, ca UPS. O agentie de stiri prin Internet ar putea oferi o componenta Web Service tuturor siturilor de Web care le publica stirile.

Web Services foloseste tehnologiile de Internet obisnuite, ca HTTP si XML, pentru a realiza comunicarea intre furnizor si consumator. În acest caz, furnizorul este cel care creeaza componenta Web Service si o distribuie prin serverul sau pentru a putea fi folosita in aplicatii de catre consumatori.

De asemenea, Web Services foloseste un nou protocol redus numit SOAP (Simple Object Access Protocol). A fost nevoie de un nou protocol fiindca o mare parte din tehnologiile de componente distribuite existente in prezent sunt legate de un sistem de operare, obligandu-ne sa rescriem obiecte pentru diferiti clienti. Problema devine mai serioasa cand se distribuie obiecte prin Internet, din cauza problemelor de securitate: majoritatea aplicatiilor de Web folosite de firmele comerciale au firewall. Daca se foloseste SOAP, care utilizeaza protocolul HTTP ca purtatoare, nu mai este necesara deschiderea de noi porturi in firewall. Comunicarea dintre furnizorul serviciului de Web si consumator se va face printr-un mesaj SOAP in format XML. Ca sa le permita consumatorilor sa foloseasca un serviciu de Web in aplicatiile lor, programatorul serviciului respectiv trebuie sa furnizeze informatii, cum ar fi metodele definite de serviciul Web, parametrii solicitati si valorile generate de metode.

Limbajul WSDL (Web Service Description Language) este cel care realizeaza acest lucru, furnizand informatii despre serviciul de Web in format XML. WSDL este generat de ASP.NET

Nota: Pentru a vedea contractul WSDL, scrieti URL-ul pentru apelarea fisierului .asmx cu sufixul ?WSDL. De exemplu, daca veti crea un fisier myWebService.asmx in http://localhost/, ati putea folosi adresa http://localhost/myWebService.asmx?WSDL pentru a vedea contractul WSDL.

Discovery of Web Services (DISCO) este mecanismul folosit pentru localizarea unui serviciu din Web. Cand se creaza in VS.NET serviciul de Web este generat si un fisier XML cu extensia .disco.

Toate serviciile de Web au extensia de fisier .asmx. Scrierea unei componente Web Service poate dura de la cateva minute la cateva zile, in functie de functionalitatea oferita. ASP.NET se ocupa de crearea contractului WSDL si de mesajul SOAP pentru comunicare.

1.2.1 Metodele serviciilor Web

Componenta Web Services contine, de regula, una sau mai multe functii publice sau private interne. WebMethod este un atribut individualizat aplicat functiilor publice pentru a permite accesul la functia respectiva clientilor de Web de la distanta. Dupa cum sugereaza si numele, functiile private nu pot fi apelate de clientii de Web de la distanta.

Functiile publice dintr-un serviciu de Web care nu are atributul WebMethod nu pot fi apelate de clientii de Web de la distanta.

Urmatorul cod defineste o metoda numita TestMethod, care are o valoare String ca intrare si genereaza o valoare String ca iesire.

Public Function TestMethod(strInput as String) as_String

‘aici vine codul de implementare’