Analiza Securitatii Serviciilor Web

Analiza Securitatii Serviciilor Web

Byadmin ianuarie 1, 2024

Analiza securitatii serviciilor web

Capitolul I. Serviciile Web

1.1 Apariția și dezvoltarea serviciilor Web

La început a fost TCP/IP-ul, acesta a avut o evoluție fantastică: a apărut în primele rețele din anii ’70 și până în zilele noastre a reușit să cucerească toată planeta. Interesant este că suita de protocoale TCP/IP a EVOLUAT, mereu s-au adus îmbunătățiri la el fără să i se întrerupă prezența în rețele și, poate mai important, fără să i se blocheze evoluția. Încă de la început, TCP/IP-ul a fost și a rămas protocol deschis, guvernat de organizații de standardizare independente ca IETF sau W3C. Oricine putea să aducă îmbunătățiri. Bineînțeles că aceste organizații se ocupă de multe alte standarde fără de care internetul de azi nu ar mai fi la fel. Există unele lucruri însă, fără de care internetul nu ar exista. TCP/IP-ul este unul din ele.

Dezvoltatorii de software au fost mulțumiți o vreme, până când nu a mai fost de ajuns să construiască aplicații care să aibă drept consumator omul. Era nevoie ca aplicațiile să comunice între ele. Aici s-a produs ruptura. Între marile companii furnizoare de tehnologie nu a mai fost același consens la problemele de comunicație între aplicații cum a fost odinioară la problemele de comunicație între calculatoare. Au fost câteva încercări dintre care s-au detașat DCOM (Distributed Component Object Model) de la Microsoft, RMI (Remote Method Invocation) de la Sun și CORBA (Common Object Request Broker Architecture) de la OMG (Object Management Group). Necazul e că nici una din cele trei tehnologii nu a fost adoptată de toată lumea.

Era nevoie ca toți să urmeze modelul standardelor deschise. Fiindcă TCP/IP-ul a fost al nimănui și a avut succes tocmai prin caracterul deschis, trebuia găsit ceva asemănător (la nivelul aplicațiilor) care să fie tot al nimănui și să fie bazat pe standarde. Acel ceva este reprezentat de serviciile web. Dacă lumea IT reușește să impună serviciile web bazate pe standarde, s-a rezolvat problema, fiindcă furnizorii de produse software vor îmbrățișa ideea de servicii web realizând produse care știu să comunice astfel cu orice alt produs indiferent de platforma pe care rulează, indiferent de cine le-a creat și indif+erent cu ce tehnologie le-a construit. Problema nu este atât de simplă, însă ideea este extraordinară și realizabilă. În ultimii ani s-au definitivat zeci de standarde în acest domeniu și suntem în faza în care putem spune că serviciile web vor avea succes cel puțin la fel ca bătrânul TCP/IP. Mai mult, pentru accelerarea standardizării și pentru oferirea unei garanții că prin serviciile web se va asigura interoperabilitatea mult dorită, s-a creat și WS-I, un organism care furnizează documente mature pentru W3C și IETF.

Lumea IT a ajuns la consens în ceea ce privește caracteristicile acelui ceva care va rezolva comunicația între aplicații. Acel ceva trebuie să fie:

independent de mașină (PC-uri, mașini mari sau dispozitive mobile), de sistemul de operare, de limbajul de programare, de baza de date sau de arhitectură,

modular,

să suporte comunicație între aplicații slab cuplate (cu gândul la internet),

utilizabile în orice domeniu, de la soluții simple P2P (Peer to Peer) la sisteme EAI (Enterprise Application Integration) și până la sisteme B2B (Business to Business) de anvergură.

Toate soluțiile de până acum (DCOM, RMI sau CORBA) au probleme majore cu cel puțin două dintre cerințele de mai sus. Trebuie să amintim aici și o soluție mai exotică numită EDI (Electronic Data Interchange), care părea să rezolve problema.

Ca să putem înțelege de ce în mintea specialiștilor în IT a apărut concepția de web-service, prin ce ea diferă de celelalte încercări de a crea tehnologii de dezvoltare a sistemelor informatice și, cel mai important, de ce e atât de bună, cum spun experții companiilor-vendori și analiștii sectorului IT, e necesar să ne intoarcem cu câțiva ani în trecut și să privim cum se dezvoltau tehnologiile creării sistemelor informatice, ce a fost creat si ce probleme au apărut. Cum se întîmpla de obicei, în totul sunt “vinovați” banii. Când rețelele de calculatoare au ieșit din cadrul organizațiilor strict militare si științifice(cum ar fi ARPAnet), ele au ajuns in mâna particularilor. În momentul în care numărul utilizatorilor a crescut a apărut ideea că rețelele de calculatoare pot fi folosite în afaceri. Astfel, rețelele de calculatoare de uz comun, principala și cea mai răspândită din care astăzi se numește Internet, au ajuns business-instrument. Dar ca să conduci un business cu un astfel de instrument, el trebuie să corespundă unui set de cerințe, cele mai importante dintre care sunt – securitatea și viteza de transfer a informației. Problema rezolvării acestor cerințe au început să o rezolve la nivelul cel mai de jos – nivelul protocoalelor de transport. Diferite companii au propus diferite realizări a protocoalelor de rețea. Protocoalele de rețea, dupa cum se știe, conțin regulile de formare a pachetelor si schimbul dintre ele. Aplicațiile ce folosesc aceste reguli (diferite pentru diferite protocoale) sunt strîns legate de aceste protocoale. Între timp relațiile B2B (Business–to–Business) cereau ca aplicațiile de rețea ce foloseau protocoale diferite să poata comunica între ele – în asa fel a aparut problema integrării aplicațiilor.

Pe parcursul câtorva ani au fost elaborate câteva tehnologii de interacționare între aplicații care permiteau, intr-un fel sau altul, realizarea schimbului de date intre aplicații (cele mai răspândite dintre care – Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) si Common Object Request Broker Architecture (CORBA)), însa fiecare dintre ele a fost destul de greu realizabilă, nu dispunea de universalitate necesară (De exemplu: Toti utilizatorii trebuiau sa aibă același sistem de operare) si, cel mai rau, aceste tehnologii erau greu compatibile intre ele. Aceasta situatie nu putea sa mulțumeasca nici business-ul, nici pe specialiștii IT.

Atunci s-a apelat la web-tehnologii de bază, s-a încercat gasirea acelui puțin, ce se afla la baza Internetului. Dar această bază e constituită din urmatoarele tehnologii:

TCP/IP – protocolul universal, acceptat de către toate dispozitivele de rețea, de la mainframe-uri la telefoane mobile si PDA;

HTML – limbaj universal, folosit pentru redarea informației cu dispozitivele utilizatorilor;

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

În fiecare definiție e conștient subliniată universalitatea fiecărei din tehnologii, pentru că această universalitate este baza ințelegerii serviciilor web. Ele sunt bazate numai pe tehnologii larg acceptate, deschise și formal independente de vendori. Doar prin intermediul acesta se ajunge la principalul avantaj al serviciilor web – universalitatea lor, adică independența de sisteme de operare, limbaje de programare, servere de aplicații, etc. Astfel, serviciile web rezolvă problema inițială – problema integrării aplicațiilor de natură diferită și construirea sistemelor informaționale distribuite. Aceasta și este diferența de bază dintre serviciile web și predecesorii săi. Cu ajutorul serviciilor web câteva, uneori total diferite, business-procese se pot integra într-un singur business-proces.

Și totuși web-services nu pot fi privite ca leac de toate business-probleme. Serviciile web, ca și multe altele, au plusurile si minusurile lor și, prin urmare, domeniile de aplicare. Necunoașterea și neconformarea în aceste domenii în proiecte reale poate duce la urmări destul de grave.

Plusurile web-service sunt:

Web-services permit companiei integrarea propriilor business-procese cu business-procese ale business-partenerilor si clienților săi cu costuri mult mai mici, decât cu alte tehnologii. Costurile unor asemenea soluții este accesibilă si IMM-urilor, ceea ce va deschide companiei noi orizonturi;

Întrucât serviciile web se organizează în regiștri publici (UDDI, ebXML), accesibili persoanelor interesate din toată lumea, pragul ieșirii companiei pe piețe noi se micșoreaza, posibilitatile cresterii bazei de clienți însa, cresc.

Serviciile web asigură compatibilitatea in relația cu sisteme informationale deja existente în companie. Astfel, se păstrează investițiile făcute anterior și nu sunt necesare schimbări radicale.

Construirea soluțiilor noi cu aplicarea serviciilor web se realizează mai rapid și mai puțin costisitor.

Neajunsurile serviciilor web:

Standardele de integrare a aplicațiilor, crearea politicilor IT si business ce pot interacționa prin intermediul serviciilor web se află încă în stadiul de continuă dezvoltare și elaborare. Mai multe companii lucrează în paralel asupra serviciilor web (Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS)) de la IBM, XLANG de la Microsoft și specificațiile WS-Coordination și WS-Transaction – rezultatul colaborării IBM, Microsoft și BEA). Evident, fără formularea strictă a lor construirea sistemelor informatice pe baza tehnologiei web-service poate merge doar cu succes intermitent.

Folosirea dinamică a informațiilor din regiștrii serviciilor web, apelul serviciilor concomitent cere rezolvarea problemelor relației de încredere între diferiți regiștri. În plus, sunt probleme în utilizarea concomitentă a regiștrilor de formate diferite.

Specificația WS-Security – produsul colaborării IBM și Microsoft – este destul de “tânără” și este mereu înnoită. Se pregătesc deja specificațiile destinate securității serviciilor Web: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

Analizând cele relatate mai sus, se poate observa că plusurile sunt de domeniul strategic, pe când minusurile au caracter tehnic, datorită noutății tehnologiilor serviciilor Web. Rezolvarea acestor probleme este doar problema de timp.

1.2 Serviciile Web

Definiția dată de organizația W3C este: un web-service este un sistem software identificat de URI [RFC 2396], a cărui interfețe publice și legăturile sunt definite și descrise folosind XML. Definirea să poată fi gasită și de alte sisteme software. Aceste sisteme pot ulterior interacționa cu web-service în 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 definiția de mai sus, observăm că unica tehnologie ce este folosită cu strictețe este XML. Nu se amintește nici de protocolul de rețea folosit, nici de limbajul de programare, nici de platforma pe care se realizează. Unica condiție – folosirea mesajelor XML (mai precis SOAP), întrucât alternativă reală pentru XML, ca limbaj ce permite lucrul cu orice tip de date, în ziua de azi nu există.

Web Services este o tehnologie .NET folosită pentru crearea de componente programabile. Multe aplicații folosesc tehnologii de componente distribuite, cum ar fi Distributed Component Object Model (DCOM) și Remote Procedure Call (RPC). O problemă comună a acestor tehnologii este dependența de platformă. Web Services folosește tehnologii de Internet standard, cum ar fi HTTP și XML. Independența de platformă creează posibilitatea și pentru sistemele eterogene de a folosi aceste aplicații. Utilizatorii nu mai trebuie să știe în ce limbaj a fost creată o aplicație sau un serviciu. Nu mai trebuie să știe decât care sunt facilitățile pe care le oferă și cum le pot utiliza în propriile lor aplicații.

Serviciile Web prezintă un uriaș potențial de utilizare într-o mare varietate de aplicații folosite în Internet, cum ar fi cele pentru serviciile meteorologice, pentru știri bursiere, pentru serviciile de știri, pentru serviciile de urmărire a pachetelor și pentru serviciile asociate. De exemplu, o firmă care vinde cărți prin Internet, cum este Amazon.com, ar putea să includă o facilitate pentru urmărirea pachetelor folosind o componentă Web Service de la o firmă de distribuție prin poștă, ca UPS. O agenție de știri prin Internet ar putea oferi o componentă Web Service tuturor siturilor de Web care le publică știrile.

Web Services folosește tehnologiile de Internet obișnuite, ca HTTP și XML, pentru a realiza comunicarea între furnizor și consumator. În acest caz, furnizorul este cel care creează componenta Web Service și o distribuie prin serverul său pentru a putea fi folosită în aplicații de către consumatori.

De asemenea, Web Services folosește un nou protocol redus numit SOAP (Simple Object Access Protocol). A fost nevoie de un nou protocol fiindcă o mare parte din tehnologiile de componente distribuite existente în prezent sunt legate de un sistem de operare, obligându-ne să rescriem obiecte pentru diferiți clienți. Problema devine mai serioasă când se distribuie obiecte prin Internet, din cauza problemelor de securitate: majoritatea aplicațiilor de Web folosite de firmele comerciale au firewall. Dacă se folosește SOAP, care utilizează protocolul HTTP ca purtătoare, nu mai este necesară deschiderea de noi porturi în firewall. Comunicarea dintre furnizorul serviciului de Web și consumator se va face printr-un mesaj SOAP în format XML. Ca să le permită consumatorilor să folosească un serviciu de Web în aplicațiile lor, programatorul serviciului respectiv trebuie să furnizeze informații, cum ar fi metodele definite de serviciul Web, parametrii solicitați și valorile generate de metode.

Limbajul WSDL (Web Service Description Language) este cel care realizează acest lucru, furnizând informații despre serviciul de Web în format XML. WSDL este generat de ASP.NET

Nota: Pentru a vedea contractul WSDL, scrieți URL-ul pentru apelarea fișierului .asmx cu sufixul ?WSDL. De exemplu, dacă veți crea un fișier myWebService.asmx în http://localhost/, ați 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. Când se crează în VS.NET serviciul de Web este generat și un fișier XML cu extensia .disco.

Toate serviciile de Web au extensia de fișier .asmx. Scrierea unei componente Web Service poate dura de la câteva minute la câteva zile, în funcție de funcționalitatea oferită. ASP.NET se ocupă de crearea contractului WSDL și de mesajul SOAP pentru comunicare.

1.2.1 Metodele serviciilor Web

Componenta Web Services conține, de regulă, una sau mai multe funcții publice sau private interne. WebMethod este un atribut individualizat aplicat funcțiilor publice pentru a permite accesul la funcția respectivă clienților de Web de la distanță. După cum sugerează și numele, funcțiile private nu pot fi apelate de clienții de Web de la distanță.

Funcțiile publice dintr-un serviciu de Web care nu are atributul WebMethod nu pot fi apelate de clienții de Web de la distanță.

Următorul cod definește o metodă numită TestMethod, care are o valoare String ca intrare și generează o valoare String ca ieșire.

Public Function <WebMethod()> TestMethod(strInput as String) as_String

‘aici vine codul de implementare’

End Function

Când se aplică atributul WebMethod() unei funcții publice, pot fi introduse și proprietăți pentru controlul temporizării, a stării sesiunii și a sectoarelorde cache. Astfel, prorietățile care pot fi specificate când se aplică atributul WebMethod() sunt:

BufferResponse: Stabilește dacă răspunsul este temporizat în memorie înainte de a fi transmis clientului. Introducerea valorii True pentru această proprietate determinată temporizarea răspunsului; intruducerea valorii False determină transmiterea răspunsului către client în momentul generării sale. Valoarea prestabilită este False.

CacheDuratioa: Stabilește durata (în secunde) de plasare în cache a răspunsului. Valoarea prestabilită este 0, astfel că răspunsul nu este salvat în cache. Dacă introduceți o valoare mai mare de 0, răspunsul va fi salvat pe durata indicată. O solicitare ulterioară în limita duratei stabilite va genera un răspuns din cache.

Description: Furnizează o instrucțiune descriptivă despre WebMethod pentru utilizatorii serviciului. această instrucțiune este afișată în dreptul de atribuire WebMethod în pagina Service Description sau Service Help.

Figura 1.1 Valoarea proprietății Description afișată în pagina Service Help.

EnableSession: Stabilește dacă este activată funcția pentru starea sesiunii a serviciului de Web. Introducerea valorii True determină activarea acestei funcții; introducerea valorii False o dezactivează. În configurația prestabilită, funcția pentru starea sesiunii este dezactivată.

MessageName: Numele folosit pentru metoda Web Service în datele transmise și primite de la o metodă Web Service. Este util când există două sau mai multe metode cu aceeași denumire.

TransactionOptions: Indică facilitățile pentru tranzacții ale metodei de Web.

1.2.2 Arhitectura soluției. Suita de tehnologii din serviciile Web (XML, SOAP, WSDL, UDDI ș.a.)

Folosirea Web Services se extinde rapid o dată cu creșterea necesităților de comunicație intre aplicații. Web Services oferind un standard de comunicare între diverse aplicații software rulând pe platforme diferite. Un Web Service este un sistem software unic identificat (URI), ale cărui interfețe publice și metoda de conectare sunt definite și descrise folosind XML. Definirea unui Web Service poate fi descoperită de către alte sisteme software. Aceste sisteme pot apoi interacționa cu Web Service-ul respectiv în maniera descrisă de definire, folosind mesaje XML.

Datorită cerințelor crescânde ale clienților și ale partenerilor de afaceri pentru informație în timp real, companiile s-au văzut silite să își conecteze sistemele disparate. Nevoia sistemelor IT de a comunica cu organizația din care fac parte a condus la evoluția Integrării Aplicațiilor unei Organizații (EAI). Această integrare foarte complexă poate fi realizată într-o manieră dinamică folosind Web Services.

Arhitectura soluției

Arhitectura de bază definește interacțiunea dintre agenții software ca un schimb de mesaje dintre consumatorii de servicii și producătorii de servicii. Agentii software pot juca 3 roluri: cel de producător de servicii, cel de consumator de servicii, respectiv cel de agenție de descoperire de servicii. Prin intemediul agentiei de descoperire, serviciile sunt publicate și pot fi găsite de consumatori.

Consumatorii și producatorii interacționează folosind unul sau mai multe modele de schimb de mesaje (Message Exchange Protocol). Componentele care respectă arhitectura de baza sunt de obicei definite folosind aplicații XML, folosesc definiții XML infoset pentru structura și tipul de date ale mesajelor și folosesc HTTP pentru transport.

Facilitățile oferite de arhitectura extinsă cuprind:

Schimb asincron de mesaje

Atașare de documente binare

Tranzacții pe durată lungă

Autentificarea mesajelor

Integritatea mesajelor

Confidențialitatea mesajelor

Specificarea căilor de urmat pentru mesaje

Gestionarea mesajelor – se permite organizarea mesajelor după anumite criterii.

Crearea de sesiuni de comunicație

Web Services pot fi implementate cu diferite formate de împachetare a datelor sau diverse modele de procesare. Datorită ubicuității standardului SOAP, acesta este folosit cu precădere în Web Services. SOAP este un protocol de schimb de informație într-un mediu descentralizat și este bazat pe protocolul XML. Deși poate sa folosească diverse metode de conectare, cel mai des folosită este HTTP.

Suita de tehnologii

Suita de tehnologii din serviciile web conține patru membri de categorie grea. Primul membru este XML iar ceilalți sunt SOAP, WSDL și UDDI.

XML

XML este o modalitate de descriere a informației și a fost creat pentru a avea un limbaj universal de a descrie orice fel de date în internet. A fost primul pas către serviciile web. Trebuia imaginat ceva simplu și ușor de transportat prin internet. Fiindcă prin rețeaua globală circulă tone de informație sub formă de HTML (web-ul nostru cel de toate zilele) a fost firesc să vină cineva cu ideea: hai să creăm un HTML extensibil, care să fie capabil să descrie orice informație. Când spunem informație, nu înseamnă numai pagini web sau documente cum este acesta ci și imagini vectoriale, tranzacții de comerț electronic, operațiuni matematice, metadate ale obiectelor etc. Așa s-a născut XML, care a devenit în scurt timp standard adoptat de W3C și este omniprezent în produsele marilor furnizori IT.

În prezent prima versiune de XML este standard și sunt definitivate specificațiile (sep. 2002) pentru XML versiunea 1.1 (Candidate Recommendation).

Documentele care sunt destinate să devină standarde în internet trebuie să treacă prin 5 faze în cadrul W3C. Documentele pot fi blocate la orice fază:

Notă – faza de idee

Draft – faza de lucru, de dezvoltare

Candidate Recommendation – faza în care se cere deja feedback de la alte grupuri de lucru sau din afara W3C

Proposed Recommendation – faza în care s-a atins consensul și se propune documentul spre aprobare

Recommendation – faza în care W3C își asumă responsabilitatea de a ”da liber” pentru implementare globală. Spunem că aici documentul devine standard de internet. Asta nu înseamnă că este obligatorie implementarea tehnologiei descrise, însă piața IT a demonstrat-o că recomandările W3C sunt adoptate pe larg de furnizorii de tehnologie IT.

XSD: Spre deosebire de HTML, XML ne permite să creăm elementele noastre așa cum vrem noi. Descrierea acestor elemente se face în documente numite XML Shema.

Aceste documente sunt tot XML însă folosesc un limbaj specific numit XSD (XML Schema Definition) a cărei primă versiune este descrisă de mai multe recomandări W3C.

Xpath: XPath (XML Path Language) este un limbaj de interogare (query) a documentelor XML. Asa cum limbajul SQL este un limbaj de interogare a bazelor de date relaționale, XPath poate și el să extragă informație din documente XML considerându-le structuri arborescente (elemente în elemente ș.a.m.d.). Aceste structuri arborescente, care abstractizează documentul XML, se numesc Information Set (pe scurt: Infoset).

În prezent, prima versiune de XPath este recomandare W3C.

XSLT: XSLT (Extensible Stylesheet Language Transformation) este o altă tehnologie care se bazează pe ideea de abstractizare a documentelor XML prin Infoset-uri și care se bazează în mare parte pe XPath. XSLT este un mecanism de transformare a documentelor XML, de exemplu de la o schema la alta.

Prima versiune de XSLT este recomandare W3C.

SAX și DOM: Procesarea (extragerea) informației (datelor) din documente XML se poate face în mai multe moduri. Una din soluții este extragerea secvențială a datelor traversând structura arborescentă a documentelor XML. Această abordare se numește SAX (Streaming API for XML) și nu este prezent în nici un document al W3C însă fiindcă este o metodă performantă de citire a datelor, soluția este implementată de majoritatea furnizorilor IT. O a doua soluție este una prin care aplicațiile pot ”naviga” înainte și înapoi în documentele XML.

Soluția se numește DOM (Document Object Model) și este recomandare W3C.

Putem vedea deci, că XML aprinde multe beculețe în mințile arhitecților software. Unul din aceste beculețe este ebXML (electronic business XML), care este rezultatul unui proiect al UN/CEFACT în colaborare cu OASIS (Organization for the Advancement of Structured Information Standards). Proiectul dorea trecerea soluțiilor EDI spre XML, ceea ce a și reușit, ba mai mult, a născut o strategie solidă în domeniul tranzacțiilor B2B însă fără aplicabilitate în EAI sau P2P. Motivul este rigiditatea sistemului de mesagerie la care dacă adăugăm scăpările de securitate, vom înțelege de ce marii furnizori de tehnologie IT și-au îndreptat atenția spre o altă tehnologie: serviciile web (XML Web Services).

Serviciile web au fost gândite de la început utilizabile în orice domeniu, să satisfacă orice cerință de mesagerie indiferent de scenariu. Arhitectural au fost gândite să fie modulare, funcționale în soluții slab cuplate și conforme cu toate specificațiile standard.

XML pare să schimbe lumea și o schimbă într-o direcție bună. Este vremea consensului. Dorința beneficiarilor de soluții IT de a avea o modalitate comună de comunicare, a determinat marii furnizori de tehnologie IT (Microsoft, IBM, Oracle, Sun, BEA, SAP, Siebel etc.) să investească miliarde de dolari în construirea de produse și soluții bazate pe servicii web. Suportul total primit de la furnizorii de platforme, de la telefoane mobile la PC-uri, servere și mașini mari (mainframe-uri), conduce la dezvoltarea unei multitudini de produse ce suportă servicii web. Aceasta înseamnă că din rețeaua virtuală globală, orice componentă (orice client, orice server, orice aplicație) poate trimite sau primi mesaje de tip XML Web Services.

Un exemplu de reprezentare în XML a descrierii unui serviciu Web care returnează HelloWorld:

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

– <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/">

– <types>

– <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">

– <s:element name="HelloWorld">

<s:complexType />

</s:element>

– <s:element name="HelloWorldResponse">

– <s:complexType>

– <s:sequence>

<s:element minOccurs="0" maxOccurs="1" name="HelloWorldResult" type="s:string" />

</s:sequence>

</s:complexType>

</s:element>

</s:schema>

</types>

– <message name="HelloWorldSoapIn">

</message>

– <message name="HelloWorldSoapOut">

</message>

– <portType name="Service1Soap">

– <operation name="HelloWorld">

</operation>

</portType>

– <binding name="Service1Soap" type="s0:Service1Soap">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

– <operation name="HelloWorld">

<soap:operation soapAction="http://tempuri.org/HelloWorld" style="document" />

– <input>

<soap:body use="literal" />

</input>

– <output>

<soap:body use="literal" />

</output>

</operation>

</binding>

– <service name="Service1">

– <port name="Service1Soap" binding="s0:Service1Soap">

<soap:address location="http://localhost/HelloWorld/Service1.asmx" />

</port>

</service>

</definitions>

Există mai multe avantaje ale serviciilor web față de alte tehnologii dar cele mai importante sunt suportul total primit de la industria IT și flexibilitatea. Pe de altă parte, cei care sunt familiari cu specificațiile organizațiilor de standardizare știu că de multe ori se folosesc cuvinte ca ”ar trebui” sau ”este posibil ca”. Pentru serviciile web, însă, s-a creat o organizație care se luptă pentru înlocuirea acestor expresii cu unele ca ”trebuie” sau ”va trebui”, ceea ce aduce o puternică reducere a ambiguităților din standarde și duce la evitarea ”interpretărilor” proprietare ale textelor. Această organizație este WS-I, care are drept scop ca implementările diferite ale suitelor de servicii web să fie interoperabile.

SOAP

Inițial SOAP se descifra ca Simple Object Access Protocol. Dacă, în urmă cu câțiva ani, întrebați pe cineva ce înseamnă SOAP primeați un asemenea răspuns: este pentru lucrul DCOM și CORBA prin Internet. Primii autori au recunoscut atunci ca ei au focusat asupra ‘accesului la obiecte’, dar cu timpul s-a dorit ca SOAP să asigure mai multe. Astfel, obiectul specificației s-a deplasat de la obiecte la schimbul cu mesajele XML. Această deplasare a creat o mică problemă cu litera O in abrevierea SOAP. Echipa de lucru SOAP 1.2 a păstrat numele SOAP, dar s-a decis să nu se mai descifreze această abreviere, ca să nu inducă în eroare dezvoltatorii. Astăzi, în definiția oficială, folosită în ultimele specificații SOAP 1.2, obiectele nici nu sunt pomenite. SOAP (Simple Object Access Protocol) reprezintă un strat important din suita de tehnologii din serviciile web și fiindcă de la apariția sa a avut o evoluție fulminantă și fiindcă în engleză sună haios, multă lume deja ignoră că numele reprezintă inițiale și îi spun simplu: SOAP (săpun).

Dacă XML este o modalitate de descriere a informației prin text simplu (documente XML), trebuia imaginat un protocol capabil să transporte aceste documente peste Internet. Acesta este SOAP, care este o tehnologie de comunicare bazată pe un mecanism de ”împachetare” a documentelor XML în plicuri SOAP (envelope – în engleză). Ideea de împachetare este asemănătoare cu ceea ce se întâmplă cu frame-urile care se împachetează în pachete IP la nivel de rețea, numai că la SOAP header-ul este – firesc – un text care se adaugă la începutul documentului XML. SOAP a fost gândit să permită conectivitatea sistemelor peste web, independent de platforma folosită. El permite ca sisteme diferite să citească, să înțeleagă și să ruteze informația din mesaje iar pentru transport poate folosi protocoale ca HTTP, HTTPS sau SMTP.

Unul din motivele pentru care SOAP a devenit extrem de popular este că e indepependent de platformă și astfel permite conectivitate indiferent de sisteme. Folosind standarde XML, sistemul receptor poate citi, înțelege și ”consuma” un mesaj SOAP indiferent de tehnologia care a emis-o. Acest lucru extinde ideea de interoperabilitate în interiorul și exteriorul companiilor consumatoare de tehnologie IT. Componentele SOAP Server și SOAP Client reprezintă interfețele către aplicațiile care cer respectiv oferă informație, transformând comunicația specifică platformei în mesaje XML independente de platformă. SOAP permite expunerea oricăror servicii în interiorul companiei, în exterior pentru eventuali parteneri sau – de ce nu – în întregul Internet, dacă e nevoie.

În prezent, SOAP este suportat de majoritatea furnizorilor IT și este menținut de W3C. Versiunea 1.2 este descrisă în trei documente care au devenit ”Candidate Recommendation” în decembrie 2002.

SOAP este format din 3 părți:

Învelișul SOAP care definește ce există în mesaj, cine trebuie să-l primească și dacă este opțional sau obligatoriu.

Regulile de împachetare SOAP care definesc un mecanism de serializare folosit pentru transferul de tipuri de date definite de aplicații.

Reprezentarea RPC SOAP care definește o convenție folosită pentru executarea de proceduri la distanță.

Această noua tehnologie, considerată de majoritatea specialistilor urmatoarea revoluție în Internet, permite atingerea unui nou nivel de performanță în crearea, menținerea și actualizarea conținutului în Internet.

SOAP creează metodele necesare accesării unui anumit conținut, fie că este vorba de un mesaj email, fie de rezultatul unei cautări intr-o bază de date. Printr-o interfață unică, același conținut poate fi folosit pe mai multe medii (de exemplu, cursul valutar poate fi afișat pe o pagină WEB, pe un PDA sau pe un telefon celular compatibil WAP). Implementările acestui protocol sunt diverse.

SOAP decide metoda transferului mesajelor XML din punctul A în punctul B(ca în imagine).

Figura 1.2 Schimb simplu de mesaje SOAP

Prima caracteristică esențială a SOAP este capacitatea sa de a se extinde. Când abrevierea SOAP mai avea o importanță, litera ‘S’ insemna ‘Simple”. Dacă ceva a putut fi invățat din Web, se datorează faptului ca simplitatea este intotdeauna mai presus decât eficiența sau calitatea tehnică, și când se pune accentul pe capacitatea de interacționare, această simplitate este absolut necesară. Simplitatea ramâne una din obiectivele de bază în dezvoltarea SOAP, fapt ce demonstrează inexistența în cadrul SOAP a capacităților sistemelor partajate, precum securitatea, rutarea, siguranța și altele. Microsoft, IBM si alti producători de sisteme operaționale, coopereaza activ pentru crearea unui pachet comun de extensii SOAP, care vor adăuga mai multe dintre posibilități, cerute de majoritatea dezvoltatorilor. Primul rezultat este Global XML Web Services Architecture (GXA).

A doua caracteristică importantă a SOAP este: poate fi utilizat în orice protocol de transport precum TCP, HTTP, SMTP si chiar MSMQ. Totuși, pentru a susține posibilitatea de compatibilitate, e necesar să fie determinată compatibilitatea cu protocoalele standard, structura cărora este diferită pentru medii diferite. Specificatia SOAP asigură o metodă flexibilă de determinare a interacțiunilor dintre protocoale și asigură o legătura evidentă pentru HTTP, care este astazi utilizat pe larg.

A treia caracteristică este: SOAP este compatibil cu toate modelele de programare si nu este legat de RPC. SOAP definește modelul prelucrării mesajelor separate și unidirecționale. Mai multe mesaje se pot întruni într-un proces de schimb de mesaje. Figura 1.2 ilustrează un mesaj simplu unidirecțional, în care emitentul nu primește răspuns. Dar destinatarul îi poate trimite emitentului răspuns (Figura 1.3).

Figura 1.3 Schema schimbului de mesaje cerere/răspuns

Dezvoltatorii adesea confundă cerere/răspuns cu RPC – acestea sunt două lucruri diferite. RPC utilizează cerere/răspuns, dar cererea/răspuns nu sunt obligatorii pentru RPC. RPC este un model de programare, care dă dezvoltatorilor posibilitatea de a lucra cu apelul metodelor. RPC necesită transformarea signaturii metodei în mesaje SOAP.

Înarmată cu aceste trei caracteristici importante, stratul de schimb de mesaje SOAP determină schimbul de mesaje XML în medii heterogene, pentru care posibilitatea de a interacționa mult timp era o problemă.

Stratul de schimb de mesaje.

SOAP determină modelul prelucrării, care conține regulile esențiale de prelucrare a mesajelor SOAP pe parcursul transportului lor de la SOAP emitent către SOAP destinatar. Figura 1.2 ilustrează un scenariu simplu de schimb de mesaje SOAP, în care o aplicație (SOAP Sender) trimite un mesaj SOAP către o altă aplicație (SOAP Receiver).

Dar modelul prelucrării admite și arhitecturi mai interesante, asemănătoare cu cea arătată în figura 1.4, care conține o mulțime de noduri intermediare.

Figura 1.4 Schimb complex de mesaje SOAP

Figura 1.5 Forma mesajelor SOAP

Un mesaj SOAP constă într-un plic format dintr-un antet (header) opțional, plus un corp (body) obligatoriu. Antetul conține blocuri de informații relevante pentru modul cum va fi procesat mesajul (date despre expeditor, despre destinatar, date de autentificare și autorizare a transmisiei etc.). Corpul va conține mesajul care va fi efectiv trimis și procesat. Se poate face analogia cu sistemul de poștă electronică folosit pe Internet, dar aici lucrurile capătă un aspect obiectual, abstract. Dacă creăm un simplu serviciu Web care returnează textul Hello + nume și îl apelăm vom obține o imagine ca acea de mai jos:

Dând clic pe legătura HelloWorld se poate vedea o descriere detaliată despre cum are loc invocarea operației implementate. Ca în captura de mai jos:

SOAP reprezintă un protocol care se comportă ca un “lipici” între componentele software eterogene, aflate pe mașini diferite. SOAP este definit să utilizeze XML și HTTP. SOAP poate fi utilizat să acceseze servicii, obiecte și servere într-o manieră independentă de platformă. Principalul său scop este tocmai facilitatea interoperabilității.

Ca concluzie se poate observa că: SOAP oferă o manieră independentă de platformă pentru vehicularea datelor marcate în XML, printr-o manieră orientată-mesaj, peste protocolul HTTP. SOAP reprezintă deci un summum între HTTP, XML și RPC, putând fi privit în acest sens ca o abordare la nivel înalt a paradigmei RPC, mai general decât RMI din Java.

EDI: Succesul EDI a fost mai ales în rândul marilor furnizori de produse de orice fel. Acești furnizori învârteau tone de hârtie pentru a furniza produsele pentru distribuitori. Trecerea la tranzacționarea electronică aducea un pas enorm: se înlocuiau tonele de hârtie cu sistemul ”computerizat” EDI. Totusi, multe din promisiunile EDI nu au fost îndeplinite deoarece multe din operațiunile manuale pe documente nu erau eliminate de aplicațiile instalate. De multe ori, după concedieri masive, companiile angajau din nou personal pentru a manipula documentele care ajungeau să fie tipărite din nou și culmea este că în final costurile totale cu EDI nu erau semnificativ mai mici decât costurile cu basculantele de hârtie. Pe de altă parte, lipsa de flexibilitate a eliminat EDI din soluțiile B2B și P2P.

DCOM și RMI: Distributed Component Object Model și urmașul său COM+ a căzut în aceeași capcană ca și Remote Method Invocation pentru că ambele tehnologii foloseau o abordare strâns cuplată. Ideea era de a conecta sistemele prin API-uri (Application Programming Interface) cu alte cuvinte de a apela funcții sau metode de pe alt calculator peste protocolul RPC (Remote Procedure Call). Acest lucru necesită un efort suplimentar de la programator fiindcă acesta trebuie să cunoască în detaliu aplicația pe care o apelează. Dacă la unul din capetele comunicației se face o modificare minoră, se compromite întregul sistem.

CORBA: Common Object Request Broker Architecture și protocolul său IIOP (Internet Inter-ORB Protocol) au reprezentat prima încercare de rezolvare a problemelor de interoperabilitate între sisteme distribuite eterogene. CORBA a fost sprijinit de multe companii IT, chiar și de comunitatea open-source, însă chiar dacă inițial părea o soluție viabilă a avut o rată de adopție modestă din mai multe motive. În primul rând era extrem de complexă și în al doilea rând proprietarii (OMG) au decis să nu mai rămână independenți de limbajul de programare și au ales EJB (Enterprise Java Beans). Astfel, fiindcă nu a mai reușit să se așeze pe standarde deschise din internet sau măcar să aducă inovații acceptate de toți, CORBA a fost și ea condamnată la implementări limitate.

EDI, DCOM, RMI și CORBA chiar dacă nu au reușit să cucerească internetul sau să obțină acordul unanim al comunității IT, reprezintă soluții extraordinare. Aceste tehnologii vor trăi încă mulți ani de acum încolo fiindcă – dacă ne gândim numai la COM+ și RMI – vom mai avea nevoie de soluții strâns cuplate. Ce este mai important e că aceste tehnologii au reprezentat pași importanți către soluțiile actuale bazate pe XML (Extensible Markup Language). Vom vorbi în continuare de XML și încă câteva tehnologii strâns legate de acesta (XSD, XPath, XSLT, SAX și DOM).

WSDL

Un document WSDL (Web Services Description Language) poate fi considerat manualul de utilizare pentru serviciile web deoarece este o descriere completă a serviciului web în cauză. Mai poate fi privit ca un contract prin care serviciul web se angajează să funcționeze într-un anumit fel. De fapt este un document XML – deci independent de platformă – care descrie metodele sau funcțiile (rutinele) utilizabile în aplicațiile noastre, descrie locația serviciului web, forma datelor pe care le primim de la funcțiile expuse și alți parametri de comunicare.

În prezent WSDL este suportat de majoritatea furnizorilor IT și este menținut de W3C. Versiunea 1.2 este descrisă de mai multe documente „Draft” aflate în lucru la W3C.

UDDI

UDDI (Universal Description, Discovery and Integration) este cel mai exotic dintre cei patru membri. Dacă putem deja să descriem datele noastre cu XML, să le transportăm cu SOAP, să construim servicii web cu Visual Studio .NET sau – nu contează cu ce – apoi să folosim WSDL pentru a descrie aceste servicii web, va trebui să găsim o soluție pentru a publica undeva serviciile web, pentru a căuta, pentru a localiza ușor servicii web care ne interesează. Acesta este UDDI și am văzut deja că seamănă cu un ”directory” de servicii web. Acest depozit de servicii web poate fi intern într-o companie sau poate fi public, în internet. Problema pare să fie simplă însă UDDI se vrea mult mai mult decât atât. De exemplu, să presupunem că am putea construi o aplicație care să consume un anumit serviciu web iar dacă acel serviciu web cade din diferite motive, aplicația noastră să fie capabilă să caute un alt serviciu web (folosind UDDI) găzduit probabil pe o altă mașină sau chiar altă platformă, să-l integreze și să continuie să funcționeze. Utilizatorul nici nu observă. Pare să fie SF, dar astfel de soluții se pot construi deja.

În prezent UDDI este suportat de majoritatea furnizorilor IT și este în lucru la OASIS.

Pentru a ușura viața dezvoltatorilor care lucrează la soluții în interiorul companiilor, Microsoft a implementat pe lângă UDDI și o variantă mai simplă, numită Disco, care nu este o soluție standard.

Până acum, serviciile web (XML Web Services) reprezintă unica suită de protocoale care satisface cele patru cerințe enumerate. Chiar dacă furnizorii din industria IT – cu câteva excepții – trec printr-o perioadă de recesiune, au făcut totuși investiții de miliarde de dolari în dezvoltarea de produse care vor furniza suite de servicii web, servere, dispozitive mobile, aplicații și unelte pentru a dezvolta aceste servicii web sau aplicații conectate.

Microsoft împreună cu alți furnizori de platforme și experți în domeniu, continuă să investească în dezvoltarea de noi specificații pentru XML Web Services. În documentele tehnice ale Microsoft, aceste noi specificații se numesc GXA (Global XML Web Services Architecture). Aceste specificații sunt rezultatul colaborării cu alți furnizori și pe măsură ce au fost elaborate, au fost supuse organizațiilor de standardizare.

Capitolul II. Securitatea Web service

2.1 Modelul de securitate a serviciilor web

Termenii care pot fi folosiți sistematic la definirea diferitor formate și mecanisme de securitate sunt:

Serviciu web – Termenul de “serviciu web” este în mare măsură aplicabil unei mari varietăți de aplicații topologice de rețea. Termenul de « serviciu web » este folosit cu scopul de a descrie componentele aplicației a cărei funcționalități și interfețe sunt accesibile utilizatorilor potențiali prin aplicarea standardelor de tehnologie web deja existente sau de-abia apărute, printre acestea numărîndu-se XML, SOAP, WSDL și HTTP. Spre deosebire de site-urile web, interacțiunea bazată pe browser sau tehnologiile dependente de platformă, serviciile web sunt servicii oferite de la calculator la calculator, prin intermediul formatelor și protocoalelor definite astfel încît să ruleze independent de platforma de operare și să fie neutre din punct de vedere al limbajului de programare.

Jetonul de securitate(Security Token) – un jeton de securitate este o reprezentare a unei informații legate de securitate (ex : certificatul X.509, tichete și autentificatori Kerberos, jetoanele de securitate a dispozitivelor mobile din cartelele SIM, numele de utilizator, etc.).

Următoarea diagramă indică cîteva din diferitele forme a jetoanelor de securitate.

Figura 2.1 Forme diferite a jetoanelor de securitate

Jetonul de securitate marcat(Signed Security Token) – un jeton de securitate marcat este un jeton de securitate ce conține un set de revendicări din domeniu aprobate criptografic de un distribuitor. Ca exemple de jetoane de securitate marcate pot servi certificatele X.509 și tichetele Kerberos.

Cererile – O cerere este o declarație despre un subiect de dialog fie de către participant, fie de un grup dependent de acesta ce asociază participantul cu cererea. Un punct important este faptul că specificația nu pretinde să limiteze tipurile de cereri ce pot fi formate, nici cum cererile acestea pot fi exprimate. Cererile pot fi cu privire la cheile potențiale, folosite ca semnătură sau pentru criptarea mesajelor. Cererile pot fi declarații pe care jetonul de securitate le transportă. Cererile pot fi folosite, de exemplu, la declararea identității expeditorului sau a unui rol autorizat.

Subiectul – subiectul unui jeton de securitate îl reprezintă un participant (ex. O persoană, o aplicație sau o entitate de business) asupra căruia se aplică cererile exprimate in jetonul de securitate. În mod specific, subiectul, fiind proprietarul jetonului de securitate deține informația necesară dovezii de proprietate a jetonului.

Dovada de proprietate – dovada de proprietate se defineste ca fiind informația folosită în procesul de dovadă a dreptului de proprietate asupra unui jeton de securitate sau a unui set de reclamații. De exemplu, dovada de proprietate poate fi o cheie privată asociată cu un jeton de securitate ce conține o cheie publică.

Polița de serviciu web terminal – serviciile web au o flexibilitate completă în specificarea cererilor pe care acestea le necesită pentru procesarea mesajelor. Acest grup de cereri necesare și informația legată de acestea sunt numite și “Poliță de serviciu web terminal”. Polițele de punct terminal pot fi declarate în XML și pot fi folosite la indicarea cerințelor legate de autentificare (ex. Dovada de utilizator sau de apartenență la un grup), autorizare (ex. Dovada unor capabilități anume de execuție), sau alte cerințe.

Cerințele de cerere – cerințele de cerere pot fi legate de mesajul sau de elementele acestuia, de toate acțiunile de un anumit tip sau acțiunilor ce au loc doar sub anumite circumstanțe. De exemplu, un serviciu poate necesita unui apelant ca acesta să se identifice pentru a achiziționa o cantitate mai mare decît o limită prestabilită.

Intermediarii – deoarece mesajele SOAP sunt trimise de la un apelant inițial spre un serviciu, acestea pot fi procesate de intermediari care execută anumite acțiuni precum rutarea mesajului sau chiar modificarea acestuia. De exemplu, un intermediar poate adăuga un antet, să encripteze sau să decripteze părți a mesajului, sau să adauge jetonuri de securitate adiționale. În asemenea situații, trebuie de avut grijă ca schimbările aplicate mesajului să nu deterioreze integritatea mesajului, să violeze modelul recunoscut sau să deterioreze responsabilitatea.

Actorul – un actor este un intermediar sau punct terminal (așa cum este definit acesta în specificațiile SOAP) care e identificat de un URI și care procesează un mesaj SOAP. Nici utilizatorii, nici soft-ul clientului (ex. Browsere) nu sunt actori.

2.1.1 Principiile modelului de securitate a serviciilor Web

Serviciile web pot fi accesate prin trimiterea de mesaje SOAP pentru deservirea terminalelor identificate de URI, care solicită acțiuni specifice și care recepționează răspunsurile mesajelor SOAP (incluzînd indicații de erori). În cadrul acestui context, scopul global al securizării serviciilor web e împărțit în țeluri auxiliare de acordare de facilități pentru securizarea integrității și confidențialității mesajelor și pentru asigurarea că serviciul e acționat doar la cerere în mesaje ce exprimă reclamațiile cerute de către polițe.

Stratul mufei securizate (SSL) împreună cu stratul de transport securizat (TLS) de facto sunt folosite la asigurarea securității la nivel de transport pentru aplicațiile de servicii web. SSL/TLS oferă cîteva facilități de securitate printre care autentificarea, integritatea datelor și confidențialitatea informației. SSL/TLS permite sesiuni punct-la-punct sigure.

IPSec este un alt standard de strat rețea ce asigură securitatea transportului ce poate deveni important pentru serviciile web. Precum SSL/TLS, IPSec de asemenea furnizează sesiuni sigure cu autentificarea gazdei, integritatea datelor și confidențialitatea informației.

Topologiile aplicațiilor de servicii web din zilele de azi sunt compuse dintr-o combinație largă de echipamente mobile, portale, servere intermediare, balanțatoare de încărcare, zone demilitarizate (DMZ), centre de informare cu surse străine de informație, și sisteme configurate dinamic și distribuite global. Toate aceste sisteme se bazează pe abilitatea intermediarilor de procesare a mesajelor să înainteze mesajele. În mod specific, modelul mesajelor SOAP operează pe terminale logice ce nu țin cont de infrastructura de rețea fizică și cea a aplicației și de aceea de multe ori include o topologie multi-hop cu actori intermediari.

Când informația este primită și înaintată de către un intermediar ce ține de un strat superior celui de transport atât integritatea informației și informația de securitate ce circulă împreună cu ea pot fi deteriorate. Acest fapt impune ca orice procesor de mesaj ce e contra curentului să se bazeze pe evaluări de securitate făcute de intermediarii precedenți și să fie încredere totală în manipularea de către aceștia a conținutului de mesaje. Ce e necesar într-o arhitectură de securizare a serviciilor web cuprinzătoare este un mecanism ce furnizează securitatea punct-la-punct. Soluțiile de securizare a serviciilor web ce au succes vor putea să acționeze atît mecanismele de securitate a stratului de transport cît și a celui de aplicație pentru furnizarea unei garnituri vaste de capabilități a securității.

Figura 2.2 Configurația punct-la-punct

Figura 2.3 End-to-end configuration

Modelul de securitate a serviciilor web descris mai sus ne permite să îndeplinim aceste țeluri printr-un proces în care :

Un serviciu web poate necesita ca un mesaj ce sosește să dovedească un set de cereri (ex. Nume, cheie, permisiuni, capabilități, etc.). Dacă un mesaj sosește fără a conține cererile necesare, serviciul poate ignora sau respinge mesajul. Noi ne referim la setul de cereri necesare și la informația legată de acesta sub numele de poliță.

Un apelant poate trimite mesaje cu dovada cererilor necesare prin asocierea jetoanelor de securitate cu mesajele. Astfel, mesajele necesită o acțiune specifică și dovadă că expeditorul lor are cererea pentru revendicarea acțiunii.

Cînd un apelant nu posedă cerințele necesare, acesta sau un reprezentant al lui poate încerca să obțină cerințele necesare prin contactarea altor servicii web. Aceste alte servicii web, la care ne vom referi ca fiind servicii ai jetonului de securitate, pot la rîndul lor să aibă setul lor propriu de cerințe. Agentul serviciilor jetonului de securitate trebuie să se încredințeze în cadrul diferitor domenii de încredere prin emiterea de jetoane de securitate.

Acest model este ilustrat în figura de mai jos, indicînd faptul că orice apelant poate de asemenea fi un serviciu și că serviciul jetonului de securitate poate de asemenea fi un integru serviciu web, care exprimă polițe și necesită jetoane de securitate.

Figura 2.4 Security token service model

Acest model general de mesagerie – cereri, polițe și jetoane de securitate – extinde și suportă cîteva modele mai specifice cum ar fi securitatea pe bază de recunoaștere a identității, liste cu control de acces și securitate pe baza de acțiuni permise. Acesta permite folosirea unor tehnologii deja existente precum certificatele cu cheie publică X.509, tichete Kerberos cu chei partajate și chiar a digest-urilor de parole. Așa cum vom vedea mai tîrziu, acesta de asemenea furnizează o abstracție integrată care permite sistemelor să construiască o punte de comunicare între diferite tehnologii de securitate. Modelul general este suficient pentru construcția schimburilor de chei de nivel superior, autentificare, autorizare, revizie și mecanisme de încredere.

2.1.2 Specificațiile de securitate a serviciilor web

Strategia de securitate arătată aici și specificațiile WS de securitate arătate mai sus formează obiectivele strategice și pilonii pentru acest model de securitate a serviciilor web propus.

Continuăm procesul de lucru cu clienții, partenerii și organizațiile de standardizare pentru a dezvolta un set inițial de specificații de securitate a unui serviciu web.

Figura 2.5 Web Services Security Specifications

Acest set va include un model de securitate a mesajelor (securitate WS – WS-Security) care furnizează bazele pentru alte specificații de securitate. Bazîndu-ne pe aceasta, vom avea un strat de polițe care va include o poliță a serviciului web terminal (poliță WS – WS-Policy), un model de încredere (WS-Trust) și un model de confidențialitate (WS-Privacy). Împreună, aceste specificații inițiale furnizează fundația pe care se poate lucra pentru strabilirea unor servicii web interoperabile între domeniile de încredere.

Bazîndu-se pe aceste specificații inițiale, se va continua lucrul cu clienții, partenerii și organizațiile de standardizare pentru furnizarea specificațiilor pe care alții le vor urma cu scopul unei securități comune care include conversații sigure (WS-SecureConversation), încrederea comună (WS-Federation) și autorizarea (WS-Authorization).

Combinarea acestor specificații de securitate permite mai multe scenarii (unele din ele sunt descrise mai jos) care sunt dificil de implementat cu mecanismele de securitate de bază din ziua de azi.

În paralel, se va propune și se va înainta cu activitățile legate de îmbunătățirea cadrului securitatății serviciilor web cu specificații legate de revizie, administrare și confidențialitate.

Combinarea specificațiilor de securitate, activităților legate de aceasta și a profilelor de interoperabilitate vor permite clienților să poată cu ușurință să implementeze servicii web de interoperabilitate sigure.

Fiecare din specificațiile propuse sunt descrise succint mai jos:

Specificații Inițiale:

WS-Securitate: descrie cum se pot atașa semnături și antete de criptare mesajelor SOAP. În plus, ea descrie cum poți atașa la mesaje jetoane de securitate, incluzînd jetoane de securitate binare precum certificate X.509 și tichete Kerberos.

WS-Poliță: descrie posibilitățile și constrîngerile polițelor de securitate (și alte chestii) în cadrul intermediarilor și punctelor terminale (de ex. Jetoanele de securitate necesare, algoritmii de criptare suportați, regulile de confidențialitate).

WS-Încredere: descrie un cadru pentru modelele de încredere care permit serviciilor web să interopereze în siguranță

WS-Confidențialitate: descrie cum serviciile web și apelanții vor specifica preferințele de confidențialitate și expunerile practice a confidențialității organizaționale.

Specificațiile ce urmează:

WS-Conversație Sigure: descrie cum să manevrezi și să autentifici schimburi de mesaje între părțile ce comunică, ce suportă schimbul de conținut și stabilirea și derivarea cheilor de sesiune

WS-Federație: descrie cum să manevrezi și să schimbi relațiile de încredere într-un mediu unit heterogen, ce suportă identități federate

WS-Autorizare: descrie cum trebuie manevrată informația de autorizare și polițele de autorizare.

Furnizarea securității serviciilor web necesită munca de rigoare în cadrul descrierii, specificării și profilelor într-un număr de domenii funcționale. Aceste documente se vor schimba și vor evoluționa printr-un proces ce balansează necesitățile clienților cu cele a comunității de dezvoltare a serviciilor web și procesului educațional propriu după cum vom vedea în continuare.

WS-Securitate

WS-Securitate descrie intensificarea efortului de a furniza calitatea protecției în cadrul mesageriei SOAP, prin integritatea mesajelor și confidențialitatea lor. De asemenea, această specificație definește cum să atașezi și să incluzi jetoane de securitate la mesajele SOAP. La urmă, va fi arătat un mecanism pentru specificarea jetoanelor de securitate binare codate (ex. Certificatele X.509). Aceste mecanisme pot fi folosite independent sau în combinație pentru acomodarea unei mari varietăți de modele de securitate și tehnologii de criptare.

WS-Securitate furnizează un mecanism de uz general pentru asocierea jetoanelor de securitate cu mesajele. Nu e necesar un jeton de securitate concret pentru WS-Securitate. Este făcut pentru a fi extensibil (de ex : suportul pentru formate multiple a jetonului de securitate). De exemplu, un apelant poate furniza dovada identității și dovada că are o anumită certificare de afaceri.

Integritatea mesajelor este furnizată prin activarea Semnăturii XML în jetoanele de securitate (care pot conține sau pot implica informație despre chei) pentru asigurarea că mesajele sunt transmise fără modificări. Mecanismul de integritate este facut pentru a suporta semnături multiple, în mod potențial de către diferiți participanți, și să fie extensibil pentru a suporta formate adiționale de semnături. Semnăturile pot indica (adică poanta) un jeton de securitate.

În mod similar, confidențialitatea mesajului este furnizată prin activarea Criptării XML în legătură cu jetoanele de securitate cu scopul de a menține confidențialitatea unor porțiuni a mesajelor SOAP. Mecanismele de criptare sunt făcute pentru a fi suportate tehnologii de criptare adiționale, procese și operații de către diferiți participanți. Criptarea poate de asemenea referenția un jeton de securitate.

În sfîrșit, Securitatea WS descrie un mecanism de codare a jetoanelor de securitate binare. În special, această specificație descrie codarea certificatelor X.509 și a tichetelor Kerberos și de asemenea modalitatea de includere a cheilor de criptare opace. El, de asemenea, include mecanisme de extensibilitate ce pot fi folosite în continuare pentru descrierea caracteristicilor jetoanelor de securitate ce sunt incluse în mesaj.

WS-Poliță

WS-Poliță descrie cum emițătorii și receptorii pot specifica cerințele și capabilitățile lor.

WS-Poliță este complet extensibil și nu plasează limite în cadrul tipurilor de necesități și capabilități ce pot fi descrise; totuși, specificația identifică cîteva atribute de bază a serviciului, incluzînd atributele de confidențialitate, formatele de codare, necesitățile jetoanelor de securitate și algoritmii suportați.

Această specificație definește un format al polițelor SOAP generic, care poate suporta mai mult decît doar polițe de securitate. Această specificație definește de asemenea, și un mecanism de atașare a polițelor de serviciu la mesajele SOAP.

WS-Încredere

WS-Încredere descrie modelul pentru stabilirea relațiilor atît directe, cît și intermediare.

Această specificație descrie cum relațiile de încredere directe existente pot fi folosite drept punct de plecare pentru intermedierea încrederii prin crearea serviciilor de emitere a jetoanelor de securitate. Acestea sunt construite pe baza WS-Securității cu scopul de a transfera jetoanele de securitate necesare într-un mod ce asigură integritatea și confidențialitatea acestor jetoane.

Această specificație descrie cum cîteva mecanisme de încredere existente pot fi folosite în legătură cu acest model de încredere.

În sfîrșit, modelul de încredere permite, în mod explicit, delegarea și impersonalizarea de către entitatea principală. Delegarea este compatibilă cu impersonalizarea, dar nu furnizează nivele adiționale de traceability().

WS-Confidențialitate

Organizațiile ce creează, administrează și folosesc serviciile web au deseori nevoie de a declara polițele lor de confidențialitate și necesită ca cererile sosite să specifice aderența emițătorului la aceste polițe.

Prin folosirea unei combinații a WS-Poliței, WS-Securității și WS-Încrederii, organizațiile pot arăta și indica conformanța cu polițele de confidențialitate declarate. Această specificație descrie un model pentru înglobarea unui limbaj privat în descrierile WS-Poliței și cum WS-Securitatea ar putea fi folosită la asocierea cerințelor de confidențialitate cu un mesaj. În fine, această specificație va descrie cum mecanismele de WS-Încredere pot fi folosite la evaluarea acestor cerințe de confidențialitate atît pentru preferințele utilizatorului, cît și pentru cerințe practice organizaționale.

WS-Conversație Sigură

WS-Conversație Sigură descrie cum un serviciu web poate autentifica mesajele apelantului, cum apelanții pot autentifica serviciile și cum se pot stabili contexte de securitate autentificată reciproce.

Această specificație descrie cum se pot stabili cheile de sesiune, cheile derivate și cheile pentru fiecare mesaj.

De asemenea, această specificație descrie cum un serviciu poate în mod sigur să facă schimb de context (colecții de cerințe privind atributele de securitate și informația legată de aceasta). Specificația descrie și este construită pe baza la emiterea jetoanelor de securitate și a mecanismelor de schimb definite în cadrul WS-Securității și WS-Încrederii. Folosind aceste mecanisme, un serviciu poate, de exemplu, suporta jetoane de securitate ce folosesc tehnologii de chei simetrice slabe și, de asemenea, poate emite jetoane de securitate mai puternice folosind chei nepartajate (asimetrice).

WS-Conversație Sigură este făcută pentru operarea pe stratul de mesaje SOAP astfel încît mesajele pot trece printr-o varietate de forme de transport și intermediari. Acest lucru nu împiedică folosirea acestuia în cadrul altor tipuri de mesagerii. Cu scopul de a crește nivelul de securitate al sistemului, nivelul de securitate al transportului poate folosi atît WS-Securitatea cît și WS-Conversație Sigură în cadrul legăturilor stabilite.

WS-Federație

Această specificație definește cum trebuie construite scenariile de încredere asociate prin folosirea specificațiilor WS-Securității, WS-Încrederii și WS-Conversație Sigură. De exemplu, aceasta descrie cum trebuie asociate infrastructurile Kerberos și PKI (așa cum este descris mai jos).

De asemenea, o poliță de încredere este folosită cu scopul de a indica, constrînge și identifica tipul de încredere.

Această specificație mai definește și mecanisme pentru administrarea relațiilor de încredere.

WS-Autorizare

Această specificație descrie cum sunt specificate și manevrate polițele de acces pentru un serviciu web. Îndeosebi aceasta descrie cum cerințele pot fi specificate în cadrul jetoanelor de securitate și cum aceste cerințe vor fi interpretate de către punctul terminal.

Această specificație este construită astfel încît să fie flexibilă și extensibilă în raport cu atît formatul de autorizare, cît și cu limbajul de autorizare. Acest lucru permite cel mai larg spectru de scenarii și asigură viabilitatea pe termen lung a cadrului de securitate.

Comparația modelelor de securitate a serviciilor Web

Modelul de securitate a serviciilor web de acum este compatibil cu cel al modelelor de securitate deja existente pentru autentificare, integritatea și confidențialitatea datelor, folosite în mod obișnuit în ziua de azi. Drept consecință, e posibilă integrarea soluțiilor bazate pe servicii web cu alte modele de securitate existente.

Securitatea Transportului – Tehnologiile existente precum (SSL/TLS) pot furniza integritate simplă punct-la-punct și confidențialitate pentru un mesaj. Modelele de securitate a serviciilor web suportă folosirea acestor mecanisme de transport sigur existente împreună cu WS-Securitatea cu scopul de a furniza integritate terminal-la-terminal și confidențialitate în special în cadrul transporturilor multiple, intermediarilor și protocoalelor de transmisiune.

PKI – La un nivel superior, modelul PKI implică autoritățile de certificare cu chei publice asimetrice și autorități ce revendică proprietăți, altele decît dreptul de proprietate al cheii (de exemplu, autoritățile de atribut). Proprietarii unor asemenea certificate pot folosi cheile asociate pentru exprimarea unei varietăți de cerințe, printre care identitatea. Modelul de securitate al serviciilor web suportă servicii a jetonului de securitate ce emit jetoane de securitate prin folosirea de chei publice asimetrice. PKI e folosit aici în sensul cel mai larg și nu presupune o ierarhie sau model oarecare.

Kerberos – Modelul Kerberos se bazează pe comunicarea cu Centrul de Distribuire a Cheilor (KDC) pentru a comunica încrederea între părțile comunicante prin emiterea de chei simetrice criptate pentru ambele părți și “făcîndu-le cunoștință” una cu cealaltă. Modelul serviciilor web, iarăși, se construiește pe baza modelului de bază, în cadrul căruia serviciile jetonului de securitate împărtășesc încrederea prin emiterea jetoanelor de securitate cu chei simetrice criptate și testamente criptate.

Însă, în timp ce modelele sunt compatibile, cu scopul de a asigura interoperabilitatea, adaptorii și/sau algoritmii comuni pentru semnătură și criptare vor necesita să fie aprobați sau dezvoltați.

Modelele existente pentru federație, autorizație (incluzînd delegarea), intimitatea și încrederea sunt mai puțin comune și mai mult ad-hoc. Specificațiile cu privire la aceste proprietăți de securitate sunt identificate în faze mai tîrzii a strategiei.

De multe ori modelele de încredere existente se bazează pe înțelegeri de afaceri. Un exemplu este serviciul web UDDI. În cadrul UDDI, sunt cîțiva participanți care furnizează un Registru Universal de Afaceri prin acordul de suport a unui set de API. Modelul de încredere din UDDI mai degrabă transferă responsabilitatea pentru autentificare nodului, care e paznicul informației, decît să definească un singur model de încredere prin necesitatea unui mecanism specific de autentificare. Astfel, orice implementare a serviciului web UDDI are mecanismul propriu de autentificare și forțează folosirea polițelor de control de acces proprii. Încrederea e între operatori și între apelant și operatorul care e paznicul informației sale.

2.2 Securitatea serviciilor Web în ASP.NET

Acest capitol descrie cum să dezvolți și să aplici tehnicile de autentificare, autorizare și comunicare sigură pentru a securiza serviciile Web din ASP.NET și mesajele serviciilor web.

Modelul de securitate al Web-Services

Securitatea serviciilor web poate fi aplicată pe trei nivele:

Securitatea la nivel de platformă/transport(point-to-point)

Securitatea la nivel de aplicație

Securitatea la nivel de mesaj

Fiecare dintre aceste soluții are diferite avantaje și neajunsuri. Alegerea unei dintre aceste soluții este strict dependentă de caracteristicile arhitecturii și a platformei implicate în schimbul de mesaje.

2.2.1 Securitatea la nivel de platformă/transport(point-to-point)

Canalul de transport între 2 capete (Web Service client și Web Service) poate fi folosit pentru a folosi securitatea point to point. Ilustrat în figura 2.1.

Figura 2.6 Securitatea la nivel de platformă

Când folosiți securitatea pe platformă, ce include o strâns legată structură Microsoft:

Web-serverul(IIS) permite autentificarea de tip: Basic, Digest, Integrated și cu Certificat.

Web-service ASP.NET moștenește câteva dintre facilitățile de autorizare și autentificare ale ASP.NET

SSL și/sau IPSec pot fi folosite pentru a asigura integritatea și confidențialitatea mesajului.

Model de securitate la nivel de transport se folosește:

Model de securitate la nivel de transport este simplu, ușor de înțeles și adecvat pentru majoritatea scenariilor(intranet-based), în care mecanismele de transport și destinația pot fi bine controlate.

Problemele principale legate de securitatea la nivel de transport sunt:

securitatea devine strans legata, si dependenta de platforma ce sta la baza, mecanismul de transport, si furnizorul serviciilor de securitate (NTLM, Kerberos, s.a.m.d)

securitatea se aplica pe o baza punct-cu-punct, fara rezerve pentru gap-urile multiple si rutarea prin nodurile intermediare ale aplicatiei.

2.2.2 Securitatea la nivel de aplicație

Interacțiunea securizată cu Web Services.

Asigurarea integrității datelor

Asigurarea confidențialității datelor

Necesitatea autentificării clientului

Securizarea unui Web Service presupune:

protejarea aplicației web de atacuri;

protejarea datelor.

Pentru protejarea aplicațiilor web de atacuri pot fi folosite atât posibilitățile serverului Web cât și posibilitățile ASP.NET.

Web-serverul IIS ne dă posibilitatea autentificării utilizatorului, utilizării mecanismelor de autorizare, de a face proecții a certificatelor utilizatorului în Windows sau Active Directory, a seta drepturile de acces la aplicații și drepturile pt aplicații însuși.

ASP.NET, la rândul său, ne dă posibilitatea de a controla executarea aplicației cu ajutorul CAS (Code Access Security), de a verifica dacă aplicația a fost sau nu modificată cu ajutorul semnăturii digitale a codului, lucrul cu rolurile, etc.

Figura 2.7 Interacțiunea securizată a serviciilor Web

Folosirea protocoalelor SSL/TLS pentru lucrul cu Web Services

Realizarea unui protocol propriu de interacționare cu Web Services

Protecția datelor la nivel de mesaj

Securitatea Web Service poate fi realizată la 3 nivele:

Securitatea la nivel de platformă/transport(point-to-point)(protocoale

SSL/TLS);

Securitatea la nivel de aplicație;

Securitatea la nivel de mesaj(WS-Security).

Selectarea soluției depinde de arhitectura aplicației aleasă.

Cea mai simplă metodă de a proteja datele transmise între Web Service și client – folosirea unui canal securizat. În acest caz aplicația apelează metoda clasei proxy, care, la rândul ei, se adreseză serviciului Web pe un canal securizat. În calitate de canal cel mai des sunt folosite protocoalele SSL/TLS.

A doua metodă de protecție a datelor – cifrarea și/sau semnarea mesajelor separate între aplicație și serviciul Web. În acest caz clasa proxy ar trebui să prelucreze fiecare mesaj, transmis de client către Web-service. Web-Service verifică și/sau descifrează mesajul și, după aceea, îl prelucrează.

A treia metodă – organizarea protecției datelor de aplicația însuși. În acest caz aplicația singură cifrează sau semnează datele, le trimite către clasa proxy, care, la rândul ei, le trimite către Web-Service. În continuare, Web-Service descifrează datele primite, le prelucrează și trimite răspuns clientului, anterior cifrându-l. Pentru această variantă și aplicația, și serviciul Web trebuie să realizeze mecanisme proprii de protecție a datelor transmise.

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

Aceasta reprezintă ce mai flexibilă și cea mai puternică metodă și este folosită de din inițiativa GXA, în special în specificația WS-Security. Securitatea la nivel de mesaj este ilustrată țn figura:

Figura 2.8 Securitatea la nivel de mesaj

Autentificarea se asigură cu ajutorul jetoanelor de securitate, care se află în headere SOAP. Nu este un model specific de de jeton pentru WS-Security. Jetoanele de securitate pot include jetoane Kerberos, certificatele X.509 sau un jeton binar.

Comunicarea sigură este asigurată de semnături digitale, pentru a asigura integritatea mesajului, și criptarea XML pentru confidențialitate.

Utilizare

WS-Security poate fi utilizat pentru crearea unui cadru de schimb de mesaje securizate într-un mediu Web heterogen. Acest sistem este potrivit pentru medii heterogene și scenarii în care nu dețineți controlul direct al configurării capetelor cât și nodurilor aplicației.

Securitatea la nivel de mesaj:

Poate fi independentă de transportul ce stă la bază;

Permite o arhitectură heterogenă de securitate;

Asigură sigurantă totală și acomodează rutarea mesajelor prin nodurile intermediare ale aplicației;

Suportă multiple tehnologii de criptare;

2.2.4 Arhitectura securității la nivel de transport

Arhitectura securității la nivel de transport a serviciilor Web în ASP.NET este prezentată în figura 2.9 de mai jos:

Figura 2.9 Arhitectura securității serviciilor Web

Figura ilustrează mecanismele de autentificare și autorizare folosite de serviciile web în ASP.NET. Când clientul apelează serviciul web, următoarele secvențe de autentificare și autorizare se petrec:

Cererea de SOAP e primită din rețea. Aceasta poate să conțină sau poate să nu conțină credențiale de autentificare în dependență de tipul autentificării folosite.

IIS autentifică opțional apelandul folosind autentificarea Basic, Digest, Integrated(NTLM sau Kerberos) sau cu Certificat. În circumstanțe heterogene, când autentificarea IIS(Windows) nu este posibilă, IIS este configurat pentru autentificare anonimă. În acest caz, clientul poate fi autentificat folosind atributele nivelului mesaj cum ar fi ticket-ele trecute în header-ul SOAP.

De asemenea IIS poate fi configurat să accepte cererile de la calculatoarele client cu adrese IP specifice.

IIS trimite semnalul(token) de acces Windows a apelantului autentificat către ASP.NET(acesta poate fi tokenul de acces a unui utilizator anonim al Internet, dacă Web service este configurat pentru autentificare anonimă).

ASP.NET autentifică apelantul. Dacă ASP.NET este configurat pentru autentificarea Windows, nu se mai petrec alte autentificări; IIS autentifică apelantul. Dacă se folosește metoda de autentificare non-Windows, modul de autentificare ASP.NET este setat ca NONE pentru a permite autentificare opțională(custom).

Notă: Autentificările Forms și Passport nu sunt suportate de către Web services.

ASP.NET autorizează accesul pentru serviciul Web apelat (fișierul .asmx) folosind autorizarea URL și File, care folosesc permisiunile NTFS asociate cu fișierul .asmx pentru a determina ce fel de acces ar trebui să fie dat apelantului autentificat.

Notă: Autorizarea File este suportată doar în cazul Autentificării Windows.

Codul din cadrul serviciului Web poate accesa resurse locale sau remote folosind identitatea particulară. În mod implicit, serviciile Web ASP.NET asigură no impersonation și, ca rezultat, procesul configurării contului ASP.NET furnizeaza identitatea . Ca opțiuni alternative sunt incluse aflarea identității apelantului,sau furnizarea identității unui serviciu configurat.

Gatekeepers (portarii, furnizorii de permisiuni)

În serviciile Web în cadrul ASP.NET gatekeepers sunt:

IIS

Dacă autentificarea anonimă nu este activată, numai IIS acceptă cereri de la utilizatorii autentificați.

Restricții legate de adresele IP. IIS poate fi configurat să accepte cereri de la calculatoare cu adrese IP specifice.

ASP.NET

Modulul HTTP de autorizare a fișierelor(doar pentru autentificarea Windows)

Modulul HTTP de autorizare a URL

Principal Permission Demands and Explicit Role Checks

2.2.5 Strategiile de autentificare și de autorizare

Această secțiune explică care opțiuni de autorizare sunt disponibile pentru un set de scheme de autentificare folosite cel mai des.

Următoarele scheme de autentificare sunt incluse aici:

Windows authentication with impersonation

Windows authentication without impersonation

Windows authentication using a fixed identity

Autentificarea Windows cu impersonare

Următoarele elemente de configurare vă arată cum să activați autentificare și impersonare Windows(IIS) prin modificări în fișierul Web.config sau Machine.config.

Notă : Dvs. Trebuie să configurați autentificarea per Web service în fiecare serviciu existând câte un fișier Web.config.

Cu această configurare, codul Web service-ului Dvs. impersonează apelantul autentificat IIS. Pentru impersonarea apelantului original,Dvs. trebuie să dezactivați accesul anonim în IIS. Cu accesul anonim, codul serviciului Web impersonează contul utilizatorului Internet(care implicit este IUSR_MACHINE).

Securitatea configurabilă

Când folosiți autentificarea Windows împreună cu impersonare, următoarele opțiuni de autorizare vă sunt la dispoziție:

Windows Access Control Lists (ACLs)

Fișierul (.asmx) Web service-ului. Autorizarea File performs verificările de acces la resursele ASP.NET cerute (care includ fișierul .asmx) folosind contextul de securitate al apelantului original. Apelantului original trebuie să îi fie posibilă macar accesul la citire(read) a fișierului .asmx.

Resursele accesate de Web service-ul Dvs. Pe resursele accesate de catre Web service-ul Dvs (fisiere, folder-e, chei de registri), Windows ACL trebuie sa includa o intrare de control a accesului (Access Control Entry), care asigura accesul pentru vizualizare apelatorului initial (deoarece poarta Web service-ului utilizata pentru accesarea resurselor impersonalizeaza apelatorul initial).

Autorizarea URL. Aceasta este configurată în fișierul Machine.config și/sau Web.config. Cu autentificarea Windows, numele utilizatorilor iau forma DomainName\UserName și rolurile se mapeaza direct cu grupurile din Windows.

</authorization>

Securitatea programatorie

Securitatea programatorie se referă la fragmente de cod din Web service ce țin de securitate. Următoarele opțiuni de securitate programatorie sunt active atunci când folosiți autentificarea și impersonarea Windows:

Principal Permission Demands

Imperative

PrincipalPermission permCheck = new

PrincipalPermission(null,@"DomainName\WindowsGroup");

permCheck.Demand();

Declarative

// Demand that the caller is a member of a specific role (for

// Windows authentication this is the same as a Windows group)

[PrincipalPermission(SecurityAction.Demand,

Role=@"DomainName\WindowsGroup")]

// Demand that the caller is a specific user

[PrincipalPermission(SecurityAction.Demand,

Name=@"DomainName\UserName")]

Explicit Role Checks. Puteți să verificați rolurile folosind interfața Iprincipal.

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

Se utilizează autentificarea și impersonarea Windows atunci când:

Clienții serviciului Web pot fi identificați folosind conturile Windows, care pot fi autentificate de server.

Dvs. aveți nevoie ca contextul securității apelantului original să circule prin Web service și pana la tier. De exemplu, un set de componente care folosesc rolurile Enterprise Services (COM+) sau utilizeaza data tier ce necesita o autorizare detaliata.

Important: Folosirea impersonării poate reduce scalabilitatea, deoarece aceasta limitează conecția cu baza de date.

Autentificarea Windows fără Impersonare

Următoarele elemente de configurare vă arată cu să activați autentificare fără impersonare în Windows(IIS) prin modificare în fișierul Web.config.

<!– The following setting is equivalent to having no identity element –>

Securitatea configurabilă

Când folosiți autentificarea fără impersonare în Windows, următoarele opțiuni de autorizare sunt la dispoziție:

Windows ACLs

Fișierul (.asmx) Web service-ului. Procedura de autorizare a fisierului executa verificari de acces pentru resursele ASP.NET apelate (care includ si fisierul .asmx al Web service-ului), folosind datele apelatorului original. Impersonarea nu este necesară.

Resursele accesate de aplicația Dvs. Pe resursele accesate de aplicatia Dvs Windows ACL trebuie sa includa un ACE care asigura acces la procesul de identitate a ASP.NET (identitatea implicita folosita de catre Web service la accesarea resurselor).

Autorizarea URL.

Aceasta se configurează în Machine.config și Web.config. Cu autentificarea Windows, numele utilizatorilor iau forma DomainName\UserName și rolurile se mapeaza direct la grupurile Windows.

</authorization>

Securitatea programatorie

Securitatea programatorie se referă la fragmente de cod din Web service ce țin de securitate. Următoarele opțiuni de securitate programatorie sunt active atunci când folosiți autentificarea fără impersonare Windows:

Principal Permission Demands

Imperative

PrincipalPermission permCheck = new PrincipalPermission(

null,@"DomainName\WindowsGroup");

permCheck.Demand();

Declarative

// Demand that the caller is a member of a specific role (for

// Windows authentication this is the same as a Windows group)

[PrincipalPermission(SecurityAction.Demand,

Role=@"DomainName\WindowsGroup")]

// Demand that the caller is a specific user

[PrincipalPermission(SecurityAction.Demand,

Name=@"DomainName\UserName")]

Explicit Role Checks. Puteți să verificați rolurile folosind interfața Iprincipal.

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

Se folosește autentificarea fără impersonare Windows când:

Clienții serviciului Web pot fi identificați folosind conturile Windows, care pot fi autentificați de server.

Doriți să utilizați un model sigur din subsistem și să autorizați clienții în cadrul Web service, și apoi să utlizați o identitate fixă pentru a accesa resursele în amonte (spre exemplu, bază de date) pentru a permite unirea conexiunilor.

Autentificarea Windows folosind identitatea fixă(Fixed Identity)

Elementul <identity> din cadrul Web.config suportă atribute opționale de nume utilizator și parolă care vă permit configurarea unei identități fixe în serviciul Web pentru impersonare. Aceasta se arată în următorul fragment din fișierul de configurare:

<identity impersonate="true" userName="DomainName\UserName"

password="ClearTextPassword" />

Această metodă nu se recomandă din 2 motive:

Numele utilizatorilor și parolele nu trebuie să fie păstrate în text plin în fișiere de configurare

În Windows 2000, această metodă vă forțează să acordați contului procesului ASP.NET privilegiul – parte a sistemului de operare. Aceasta reduce securitatea serviciului Web și îi dă posibilitatea atacatorului de a compromite procesul serviciului Web (Aspnet_wp.exe).

2.2.6 Configurarea securității

Această secțiune ne arată pașii practici spre configurarea securității unui Web service în ASP.NET. Ei sunt prezentați în figura de mai jos.

Figura 2.10 Configurarea securității ASP.NET

Figura 2.11 Pașii practici necesari pentru a securiza o aplicație Web în ASP.NET

Configurarea setărilor IIS.

Pentru a configura securitatea IIS trebuie să executăm următorii pași:

Instalați instalați certificatul serverului Web (dacă aveți nevoie de SSL)

Configurați autentificarea IIS

Configurați maparea certificatelor client(dacă folosiți autentificarea cu certificat)

Setați permisiunile NTFS pentru fișiere și foldere. IIS și ASP.NET verifică dacă utilizatorul autentificat are drepturi necesare de acces pentru acel fișier.

Configurarea setărilor ASP.NET

Setările la nivel de aplicație sunt făcute în fișierul Web.config, care este situat în directoriul virtual al serviciului Web. Configurați următoarele setări:

1. Autentificarea. Aceasta trebuie să fie o setare per-Web service(nu în Machine.config) în fișierul Web.config situat directoriul virtual al serviciului Web.

Notă: Serviciile Web nu suportă autentificarea Passport sau Forms. Pentru autentificarea la nivel de aplicație(custom) și la nivel de mesaj setați modul la None.

2. Impersonarea și Autorizarea.

Dezactivarea HTTP-GET și HTTP-POST

Implicit, clienții pot comunica cu serviciile Web din ASP.NET folosind trei protocoale: HTTP-GET, HTTP-POST și SOAP peste HTTP.Dvs. trebuie să deactivați suportul pentru două dintre ele . Protocoalele HTTP-GET și HTTP-POST trebuie să fie deactivate la nivel de mașină pe acele calculatoare care nu au nevoie de ele. Aceasta este pentru a evita o potențială breșă în securitate prin intermediul căreia o pagină Web infectată poate accesa un Web service intern ce rulează după un firewall.

Notă: Prin dezactivarea acestor protocoale clientul nu va mai avea posibilitatea testării unui Web service folosind butonul Invoke din pagina de test a serviciului Web. In shimb, trebuie să creați un program client test prin adăugarea unei referințe la Web service folosind sistemul de dezvoltare Microsoft Visual Studio. NET. S-ar putea să doriți păstrarea acestor protocoale pe calculatoarele dezvoltatorilor pentru a permite acestora utilizarea paginii test.

Pentru a dezactiva protocoalele HTTP-GET și HTTP-POST în întreg calculator:

Editați Machine.config.

Liniile în interiorul <webServices> ce activează suportul protocoalelor HTTP-GET și HTTP-POST le marcăm ca comentarii. În rezultat, Machine.config ar trebui să arate în felul următor:

<!– <add name="HttpPost"/> –>

<!– <add name="HttpGet"/> –>

</protocols>

</webServices>

Salvați Machine.config

Notă: Pentru cazurile speciale, când Dvs. aveți clienții serviciului Web care comunică cu serviciul Web folosind aceleași HTTP-GET și HTTP-POST, puteți să adăugați suportul pentru aceste protocoale în fișierul web.config al aplicației.

2.2.7 Trimiterea credențialelor pentru autentificare către Web Service

Cînd apelați serviciul Web o faceți folosind proxy; un obiect local care arată același set de metode ca și serviciul țintă. Puteți genera Web service proxy folosind linia de comandă a utilitei Wsdl.exe. Alternativ, dacă folosiți Visual Studio .NET puteți genera proxy adăugând referință web la proiect.

Notă: Dacă serviciul Web pentru care doriți să generați proxy este configurat pentru cererea certificatelor client, această setare trebuie oprită atât timp cât adăugați referința. După ce ati adăugat referința trebuie să porniți cererea.

Specificarea credențialelor clientului pentru autentificarea Windows

Dacă folosiți autentificarea Windows, trebuie să specificați credențialele utilizate pentru autentificare folosind proprietatea Credentials al Web service-ului. Dacă nu setați această proprietate explicit, serviciul Web va fi apelat fără credențiale. Dacă autentificarea Windows este obligatorie, se va returna o eroare HTTP status 401, acces refuzat.

Folosirea DefaultCredentials

Credențialele clientului nu circulă implicit. Consumatorul serviciului Web trebuie să seteze credențialele și detaliile de autentificare în proxy. Puteți seta proprietățile Credentials a proxy-ului serviciului Web după cum se arată mai jos.

proxy.Credentials =

System.Net.CredentialCache.DefaultCredentials;

Să luați în vedere următoarele puncte înainte să folosiți această metodă:

Aceasta permite ca credențialele clientului să circule numai atunci când folosiți autentificarea NTLM, Kerberos sau Negotiate.

Dacă aplicația de partea clientului (de exemplu: aplicația Windows Forms) apelează serviciul Web, credențialele sunt obținute din sesiunea interactivă de logare a utilizatorului.

Aplicațiile de partea serverului, cum ar fi aplicațiile ASP.NET Web, folosesc identitatea procesului, numai dacă impersonarea nu este configurată, caz în care identitatea impersonată a apelantului este utilizată.

Folosirea credențialelor specifice

Pentru a folosi setul specific de credențiale pentru autentificare atunci când apelați Web service, folosiți următorul cod:

CredentialCache cache = new CredentialCache();

cache.Add( new Uri(proxy.Url), // Web service URL

"Negotiate", // Kerberos or NTLM

new NetworkCredential("username", "password", "domainname") );

proxy.Credentials = cache;

În exemplul de mai sus, autentificarea prin Negociere cerută rezultă fie în Kerberos sau NTLM tip de autentificare.

Setarea proprietății de Preautentificare

Proprietatea de preautentificare a proxz poate fi setată la true sau false. Aceasta se setează la true pentru a furniza credențiale specifice de autentificare ce vor cauza trecerea de header-ul WWW-authenticate HTTP printr-o cerere Web. Aceasta salvează refuzarea accesului la cerere, și executarea autentificării la următoarea cerere de acces.

Notă: Pre-autentificarea se aplică doar după ce Web service-ul autentifică cu succes pentru prima dată. Pre-autentificare nu are nici un impact asupra primei cereri.

private void ConfigureProxy( WebClientProtocol proxy,

string domain, string username,

string password )

{

// To improve performance, force pre-authentication

proxy.PreAuthenticate = true;

// Set the credentials

CredentialCache cache = new CredentialCache();

cache.Add( new Uri(proxy.Url),

"Negotiate",

new NetworkCredential(username, password, domain) );

proxy.Credentials = cache;

proxy.ConnectionGroupName = username;

}

Apelarea serviciului Web de clienții Non -Windows

Există câteva abordări a autentificării care lucrează pentru scenariile cross-browser. Acestea includ:

Autentificare prin Certificat. Prin folosirea certificatelor X.509.

Autentificare Basic

GXA Message Level Approaches. Folosește Web Service Development Toolkit.

Alte abordări.

Autentificarea Proxy Server

Autentificarea proxy server nu este suportată de către căsuța de dialog la primele versiuni Visual Studio.NET Adăugarea unei referințe Web . Ca rezultat poate apărea un HTTP status 407: Autentificarea proxy este necesară, când se va încerca adăugarea unei referințe Web.

Notă: S-ar putea să nu vedeți această eroare când vizualizați fișierul .asmx printr-un browser, deoarece acesta transmite automat credențiale.

Pentru a remedia această problemă, se poate folosi comanda Wsdl.exe, după cum urmează:

wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword> /pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx

Dacă aveți nevoie să setați informația de autentificare a proxy, folosiți următorul cod:

YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;

2.2.8 Transferul Apelatorului Original

Această secțiune descrie cum se poate transfera contextul de securitate a utilizatorului original printr-o aplicație Web ASP.NET către un Web service localizat pe alt server. S-ar putea să trebuiască să faceți aceasta pentru a suporta autorizarea pre-utilizator în cadrul Web service sau în cadrul altor sisteme în amonte (spre exemplu, baze de date, unde doriți să autorizați apelanții originali la obiectele bazei de date).

În figura 2.12, contextul de securitate al apelatorului original se transferă prin Web service de intrare care conține aplicația Web ASP.NET, spre obiectul distanțat, deținut de ASP.NET pentru un alt server, și în final către un server de baze de date back end.

Figura 2.12 Transferul contextului de securitate apelatorului original

Pentru a transmite credențialele către un Web service, clientul (aplicația ASP.NET în acest scenariu) trebuie să configureze proxy al Web service și să seteze explicit proprietățile Credentials.

Există două metode pentru a transfera contextul apelatorului:

Transferarea credențialelor implicite și utilizarea autentificării Kerberos. Această abordare necesită configurarea proxz cu DefaultCredentials obținute de la contextul de securitate al apelatorului impesonat.

Transferarea credențialelor explicite și utilizarea metodelor Basic sau Froms de autentificare. Această abordare nu necesită impersonarea prin aplicația ASP.NET. În schimb, se va configura proxy al Web service cu credențialele explicite obținute fie de la variabilele de server (prin autentificare Basic) sau prin câmpurile formularelor HRML (prin autentificarea Form) care sunt disponibile pentru aplicația Web. Cu autentificarea Basic sau Form, numele utilizatorului ți parola sunt disponibile serverului în text clar.

Subsistem de încredere

Modelul subsistemelor de încredere furnizează o abordare alternativă la transferul contextului apelatorului original. In acest model există un hotar de încredere între Web service și aplicația Web. Web service are încredere în aplicația Web pentru a autentifica și autoriza apelatorii, înainte de înaintarea cererilor de autentificare către Web service. Nu se realizează autentificarea apelatorilor originali în cadrul Web service. Web service-ul autorizează identitatea aplicației Web pentru a realiza autentificarea apelatorilor originali. În majoritatea cazurilor acesta este procesul de lucru al ASP.NET:

Accesarea resurselor rețelei

Când accesați resursele de rețea prin Web service, trebuie să considerați identitatea ce este utilizată pentru a răspunde la necesitățile de autentificare de pe calculatorul remote. Există trei opțiuni:

Identitatea procesului (determinată de către contul utilizat pentru a rula procesul ASP.NET)

Identitatea serviciului (spre exemplu, cea creată prin apelarea LogonUser)

Identitatea apelatorului original (dacă Web service este configurat pentru impersonalitate).

2.2.9 Utilizarea certificatelor client cu Web Service

Această secțiune descrie tehnicile pentru utilizarea certificatelor client X.509 pentru autentificarea Web service.

Se pot folosi certificate client pentru autentificarea Web service în cadrul:

Altor servicii Web;

Aplicațiilor ce comunică direct cu Web service (spre exemplu, aplicațiile desktop bazate pe platforme server sau client-side).

Autentificarea Clienților Web browser prin certificate

Un web service nu poate folosi certificatele client pentru autentificarea apelatorilor dacă aceștia interacționează cu o aplicație intermediară Web, deoarece nu este posibil transferul certificatului apelatorului original prin aplicația Web către Web service. În timp ce aplicația Web poate autentifica clienții cu certificate, aceleași certificate nu pot fi utilizate de către Web service pentru autentificare.

Motivul ratării în acest scenariu server-către-server este faptul că aplicația Web nu are acces la certificatele clienților (în special către cheia privată) aflată în depozitul de certificate. Această problemă este ilustrată în figură:

Figura 2.13 Autentificarea către Web service cu certificatul clientului

Utilizarea Modelului Sistem de Încredere

Pentru a accesa această restricție, și pentru a susține autentificarea certificatelor pe Web service, trebuie utilizat un subsistem de încredere. Cu această abordare, Web service autentifică aplicația Web folosind certificatul acesteia. Web service trebuie să fie sigur în aplicația Web pentru a autentifica utilizatorii acesteia, și pentru a executa autorizările necesare, în scopul asigurării că doar apelatorii autorizați pot să acceseze informația și funcționalitățile expuse pe Web service.

Figura 2.14 Serviciul Web autentifică aplicația Web de încredere

Dacă logica autorizării în cadrul Web service necesită roluri multiple, aplicația Web poate transmite certificate diferite bazate pe apartenența apelatorului. Spre exemplu, un certificat poate fi utilizat pentru membri grupului de administratori (care pot modifica informațiile) și altul pentru ceilalți utilizatori (cărora le este permisă doar vizualizarea).

Notă: În cadrul acestor scenarii, un server local de certificare (accesibil doar de alți doi server) poate fi utilizat pentru gestionarea tuturor certificatelor aplicației Web.

În acest caz:

Aplicația Web autentifică utilizatorii prin folosirea certificatelor clienți;

Aplicația web are rol de gatekeeper și autorizează utilizatorii și controlează accesul acestora la Web service;

Aplicația Web apelează Web service și transmite diferite certificate ce reprezintă aplicația (sau mai multe certificate bazate pe apartenența de grup a apelatorilor);

Web service autentifică aplicația web și are încredere în aceasta pentru a executa autorizarea necesară a clienților;

IPSec este utilizată între aplicația Web și Web service pentru a asigura control adițional al accesului. Accesul neautorizat este prevenit de către IPSec. Autentificarea prin certificate pe serverul de Web service de asemenea previne accesul neautorizat.

Implementarea Soluției

Pentru a utilizarea autentificare prin certificate în cadrul Web service în acest scenariu, se folosește un proces separat pentru a apela Web service și a transmite certificatul. Nu se pot manipula certificatele direct de la aplicația Web ASP.NET, deoarecea aceasta nu are încărcate profilurile utilizatorilor. Un proces separat trebuie configurat pentru a rula prin folosirea unui cont ce are un profil de utilizator asociat. Există două opțiuni principale:

Poate fi utilizată aplicația server Enterprise Service;

Poate fi utilizat Windows service.

Figura 2.15 Autentificarea client certificate cu Web service

Secvența evenimentelor ilustrate în figură:

Apelatorul original este autentificat de către aplicația Web folosind certificatele client.

Aplicația Web este gatekeeper și este responsabilă pentru autorizarea accesului la ariile specifice de funcționalitate (inclusiv acele ce implică interacțiunea cu Web service).

Aplicația Web apelează o componentă deservită rulând un proces pe aplicația Enterprise Service

Contul utilizat pentru rularea aplicației Enterprise Service are un profil de utilizator asociat. Componenta accesează certificatele client de la depozitul de certificate, care sunt emise de către Web service pentru a autentifica aplicația Web.

Componenta deservită apelează Web service, transferând certificatele client la fiecare cerință. Web service autentifică aplicația Web folosind aceste certificate, și are încredere în aplicația Web pentru a autoriza corect utilizatorii originali.

Capitolul III. Aplicații practice

3.1 Lucrul cu protocolul SSL/TLS

3.1.1 Protocoalele SSL/TLS

Protocoalele SSL/TLS sunt protocoalele la nivel de transport și servesc pentru instalarea legăturii de încredere între server și client.

Pentru instalarea unei asemenea legături serverul trebuie să aibă un certificat digital.

Protecția datelor la nivelul protocolului de transport este destul de simplă de realizat și de înțeles, de aceea ea este cel mai des utilizată pentru asigurarea accesului securizat la pagini și servicii Web. Protocoalele cel mai des folosite la nivel de transport sunt SSL(Secure Socket Layer) și TLS(Transport Layer Security). Protocoalele SSL/TLS sunt standarde – în acest fel, ele asigură integrarea aplicațiilor-client și serviciilor Web independent de platforma folosită.

Pentru interacțiunea cu serviciul Web se folosește protocolul HTTPS – protocolul HTTP în conjuncție cu protocolul SSL/TLS.

Pentru interacțiunea cu serviciul Web este deajuns să setăm serverul Web și în rândul de adresa a serviciului web sa indicam https://…. Astfel, apelarea metodei web-service se desfasoara absolut discret atat pentru aplicatia client, cat si pentru Web-service.

Protocoalele SSL/TLS permit nu numai autentificarea serverului și protecția datelor transmise, ele dau posibilitatea și de a autentifica clientul cu ajutorul certificatului lui digital. Microsoft .NET Framework permite folosirea a amândouă variante: cu una, sau cu doua autentificări. În primul caz e necesar doar certificatul serverului cu Extended Key Usage, în al doilea – e necesar certificatul serverului, cât și a clientului cu Extended Key Usage – Client Authentication.

3.1.2 Setarea serverului Web pentru lucrul cu protocolul SSL/TLS

Pentru instalarea SSL/TLS pe serverul Web e necesar:

Formularea cererii unui certificat pentru fiecare sit;

Recepționarea și instalarea certificatului;

Aplicarea flag-ului pentru cererea de conexiune securizate cu serverul;

Pentru autentificarea clientului este, de asemenea, necesara aplicarea flag-ului utilizarii certificatelor client.

SSL este un set de tehnologii criptografice care asigura autentificarea, confidentialitatea si integritatea datelor. SSL este cel mai utilizat pentru a crea canale securizate de comunicatii intre browsere Web si servere Web. De asemenea, poate fi utilizat intre aplicatiile client si servicii Web.

Cerințe tehnice:

Pentru a seta utilizarea protocolului SSL pe serverul Web dumneavoastră aveți nevoie de următoarele:

Sistem de operare Microsoft® Windows 2000 Server

Autoritatea de certificare Microsoft.

Internet Information Server instalat

În acest exemplu vom vedea cum:

Se generează o cerere pentru un Certificat

Se completeaza cererea pentru Certificare;

Se eliberează un certificat

Se instalează Certificatul pe Web server

Se configurează serverul să folosească SSL Access

Generarea cererii pentru un Certificat

Această procedură creează o nouă cerere pentru un certificat, care poate fi trimisă la Autoritatea de Certificare(CA) pentru procesare. În caz de succes, CA va trimite înapoi un fișier ce conține un certificat valid.

Pentru a genera o cerere pentru Certificat

Porniți consola IIS Microsoft Management Console (MMC).

Expandați numele serverului Web și selectați situl Web pentru care doriți să instalați certificatul.

Right-click the Web site, and then click Properties.

Click the Directory Security tab.

Executați click pe butonul Server Certificate în cadrul Secure Communications pentru a lansa Web Server Certificate Wizard.

Executați click pe Next pentru a trece de mesajul de întîlnire.

Click pe Create a New Certificate, și pe urmă Next.

Apar următoarele 2 opțiuni:

Pregătim cererea acum, dar o trimitem mai târziu(Prepare the request now, but send it later). Această opțtiune este mereu disponibilă.

Trimitem cererea imediat către o autoritate de certificare online(Send the request immediately to an online certification authority). Această opțiune este disponibilă doar dacă serverul Web poate accesa unul sau mai multe servere de certificare Microsoft. Mai târziu, în procesul cererii, ni se dă oportunitatea de a selecta o autoritate dintr-o listă pentru a-i trimite cererea.

Executați click pe Prepare the request now, but send it later, și pe Next.

Introduceți un nume descriptiv pentru certificat în boxa Name, introduceți lungimea de biți a cheii dorită în Bit length, apoi click Next.

Introduceți numele organizației și click Next.

În Common name, introduceți numele sitului Dvs., click Next.

Introduceți informațiile lgate de locația Dvs., click Next.

Introduceți numele pentru fișierul de cerere pt certificat.

Fișierul conține informația similară cu:

––BEGIN NEW CERTIFICATE REQUEST––

MIIDZjCCAs8CAQAwgYoxNjA0BgNVBAMTLW1penJvY2tsYXB0b3Aubm9ydGhhbWVyÃ‚Â…

––END NEW CERTIFICATE REQUEST––

Aceasta este o reprezentare a cererii pt certificat codată Base 64. Cererea conține informația introdusă anterior și, de asemenea, cheia publică și informația semnată cu cheia Dvs. Privată.

Acest fișier-cerere este trimis către CA. CA folosește cheia Dvs. publică din cererea pt certificat pentru a verifica informația semnată cu cheia Dvs. privată.

După ce completați cererea către CA, CA vă întoarce un certificat într-un fișier. După aceea trebuie să restartați Web Server Certificate Wizard .

Click Next.

Click Next, și pe urmă Finish.

Cererea pt certificat acum poate fi trimisă către CA pentru verificare și procesare. După ce primiți răspuns de la CA, puteți să continuați și să instalați certificatul pe Web server, folosind încă o dată IIS Certificate Wizard.

Înregistarea unei cereri pentru Certificat

Această procedură folosește Microsoft Certificate Services pentru a trimite cererea de Certificat generată în procedura anterioară.

Pentru a trimite o cerere de Certificat

Folosiți Notepad pentru a deschide fișierul certificat generat în procedura anterioară și copiați întregul lui conținut în clipboard.

Porniți Internet Explorer și navigați către http://hostname/CertSrv, unde hostname este numele calculatorului ce găzduiește Microsoft Certificate Services.

Click pe Request a Certificate, și pe urmă pe Next.

Pe pagina cu Choose Request Type executați click pe Advanced request, apoi Next.

În pagina Advanced Certificate Request, click Submit a certificate request using a base64 encoded PKCS#10 file, apoi click Next.

În pagina Submit a Saved Request, executați click pe căsuța Base64 Encoded Certificate Request (PKCS#10 or #7) și apăsați Ctrl+V pentru a introduce cererea de certificat pe care ați copiat-o în clipboard mai devreme.

Selectați Web Server din Certificate Template.

Click Submit.

Închideți Internet Explorer.

3.1.5 Emiterea Certificatului

Pentru a emite certificatul

Porniți Certification Authority din grupul de programe Administrative Tools.

Expandați autoritatea Dvs. de certificare, și selectați mapa Pending Requests.

Selectați cererea de certificat pe care tocmai ati trimis-o

În meniul Action, apăsați All Tasks, după care pe Issue.

Asigurati-vă că certificatul este afișat în mapa Issued Certificates, și executați dublu-click pentru a-l vedea.

În meniul Details, click Copy to File, și salvați certificatul ca Base-64 encoded X.509.

Închideți fereastra de proprietăți ai certificatului.

Închideți fereastra Autorității de Certificare.

Instalarea Certificatului pe serverul Web

Această procedură instalează certificatul emis în procedura anterioară pe serverul Web.

Pentru a instala certificatul pe serverul Web

Porniți Internet Information Services.

Expandați numele serverului Dvs. și selectați situl Web pentru care doriți să instalați certificatul.

Executați right-click pe sit și selectați Properties.

Click pe Directory Security.

Click pe Server Certificate pentru a lansa Web Server Certificate Wizard.

Click Process the pending request and install the certificate, apoi executați click pe Next.

Introduceți adresa și numele fișierului ce conține răspunsul de la CA, apoi click Next.

Studiați datele din certificat, click Next, apoi Finish.

Din momentul acesta certificatul este instalat pe server Web.

Configurarea resurselor pentru cererea SSL Access

Această procedură folosește Internet Services Manager pentru a configura directorul virtual să ceară SSL pentru a-l accesa. Dv. Puteți să setați folosirea SSL pentru fișiere, directoare sau directoare virtuale specifice. Clienții sunt obligați să folosească protocolul HTTPS pentru a accesa asemenea resurse.

Pentru a configura resursele să folosească SSL access

Porniți IIS.

Expandați numele serverului și situl(Acesta trebuie să fie un sit cu un certificat instalat).

Right-click pe directorul virtual, apoi click Properties.

Click Directory Security.

În cadrul Secure Communications apăsați Edit.

Bifați în dreptul Require secure channel (SSL). Din momentul acesta clientul trebuie să folosească HTTPS.

Click OK, apoi închideți fereastra de proprietăți.

Închideți IIS.

3.2 Folosirea protocoalelor SSL/TLS în serviciile Web

Pentru verificarea securizării conexiunii se folosește proprietatea IsSecureConnection a proprietății Request din obiectul Context.

Lista certificatelor utilizatorului de asemenea este disponibilă prin proprietatea Request.

Obiectul Context reprezinta contextul utilizatorului respectiv al Web service.

Pentru un schimb de date cu Web service securizat e de ajuns setarea Web serverului, dar câteodată e necesar să verificăm se folosește sau nu conexiunea securizată în însuși Web Service. Pentru asemenea scopuri se folosește proprietatea IsSecureConnection din clasa System.Web.HttpRequest. Ea ne indică, se folosește protocolul HTTPS pentru accesul la resurse sau nu.

Pentru autentificarea clientului cu ajutorul certificatelor se folosește proprietatea ClientCertificates din aceeași clasă. Ea returnează o colecție de obiecte a clasei HttpClientCertificate, din care se pot ușor obține certificatele clientului.

Folosirea protocoalelor SSL/TLS din partea clientului pentru accesul la serviciile Web

E necesar să indicați calea către serviciul Web cu prefixul https://

Pentru autentificarea clientului e necesar ca în proxy-class să fie adăugate certificatele utilizatorului în colecția ClientCertificates

Pe partea clientului pentru schimbul sigur cu Web-service este necesar de a folosi protocolul https. La conectarea cu Web-server SSL-client primește certificatul serverului și îl verifică. Dacă rezultatul este pozitiv el verifică dacă corespunde partea distinguished name (CN) cu adresa sitului. De exemplu, la accesarea paginii sau a serviciului Web pe adresa http://devgroup.mephist.ru/pki/test certificatul serverului trebuie să fie emis pe numele devgroup.mephist.ru. În cazul în care numele serverului din certificat nu corespunde cu calea lucrul cu Web service va fi întrerupt. În cazul accesării paginii din Internet Explorer va fi afișată o avertizare corespunzătoare, dar lucrul cu pagina va fi posibil.

Pentru autentificarea utilizatorului este necesar de a adăuga certificatele clientului în colecția ClientCertificates a clasei proxy Serviciului dat. La apelarea metodei serviciului Web certificatele clientului vor fi transferate serverului.

La folosirea prefixului https în adresa clasa SoapHttpClientProtocol automat va încerca să instaleze o legătură securizată cu Web-server. De obicei pentru aceasta se folosește portul 443. În afară de aceasta, toate certificatele din colecția ClientCertificates clasei proxy din Web service vor fi transmise web-serverului pentru autentificarea clientului.

Acum clientul poate interacționa cu Web service prin canal securizat.

Autentificarea utilizatorului

La autentificarea utilizatorului folosind certificatele serviciul Web primește certificatul clientului cu ajutorul proprietății ClientCertificate a obiectului Context.Request.

Certificatele se prezintă sub forma unei mase de baiți. Pentru verificarea certificatelor e necesar de a folosi clasa X509CertificateEx.

În clasa proxy de partea clientului e necesar de a adăuga certificatele utilizatorului în colecția ClientCertificates.

În cazul autentificării pe baza certificatelor digitale e necesar de a seta corect serverul pentru recepționarea certificatelor clienților.

De partea clientului e de ajuns să adăugăm certificatele în colecția certificatelor utilizatorului. Aceasta se poate realiza în constructorul clasei proxy sau chiar în aplicația clientului:

CodeForLab3.Service SSLDemo=new CodeForLab3.Service();

SSLDemo.ClientCertificates.Add(x509cert);

De partea serverului e necesar de a efectua următorii pași:

de a recepționa certificatul pentru web-server.

de a permite recepționarea certificatelor de la client.

De partea serverului certificatul este accesibil prin proprietatea ClientCertificate a obiectului Context.Request.

În versiunea curentă .Net Framework și ASP.NET serviciile Web pot lucra cu un certificat al utilizatorului, dar de partea clientului e posibilă adăugarea câtorva certificate ale clientului.

3.3 Apelarea Web service folosind SSL

Puteți configura Web service să folosească Secure Sockets Layer(SSL) pentru a proteja

date sensibile între client și serviciu. SSL aduce:

Integritatea mesajului. Aceasta asigură că mesajele nu sunt modificate cât sunt în tranzit.

Confidențialitatea mesajului. Aceasta asigură că mesajul rămâne privat cât se află în tranzit.

Acest capitol descrie cum trebuie configurat serviciul Web pentru folosirea SSL și cum să apelezi serviciul Web dintr-o aplicație client ASP.NET folosind protocolul HTTPS.

Acest capitol include următorii pași:

Crearea unui Web service

Configurarea directorului virtual a serviciului Web să folosească SSL

Testarea serviciului Web folosind un browser

Instalarea certificatului pe calculatorul client

Dezvoltarea aplicației Web pentru a apela Serviced Component

Crearea unui Web service

Mi-am propus să creez un serviciu Web ce returnează un text, introdus anterior, criptat folosind algoritmul de criptare DES.

Pentru a crea un Web service pe calculatorul gazdă:

Porniți Visual Studio .NET și creați o nouă aplicație C# ASP.NET Web Service numită CryptoService.

Redenumiți service1.asmx în crypto.asmx.

Deschideți crypto.asmx.cs și redenumiți clasa Service1 în crypto.

Înlocuiți codul clasei crypto:

using System;

using System.Collections;

using System.ComponentModel;

using System.Data;

using System.Diagnostics;

using System.Web;

using System.Web.Services;

using System.Security;

using System.Security.Cryptography;

using System.IO;

using System.Text;

namespace WebService1

{

public class crypto : System.Web.Services.WebService

{

public crypto()

{

InitializeComponent();

}

private void InitializeComponent()

{

}

private static byte[] EncryptData(byte[] inName, byte[] desKey, byte[] desIV)

{

//Create the file streams to handle the input and output //files.

FileStream fin = new FileStream("tempIn.dat",

FileMode.Create, FileAccess.Write);

FileStream fout = new FileStream("tempOut.dat",

FileMode.Create, FileAccess.Write);

fout.SetLength(0);

//Create variables to help with read and write.

byte[] bin = new byte[100]; //This is intermediate //storage for the encryption.

long rdlen = 0; //This is the total number of bytes //written.

//This is the total length of the input file.

int len;//This is the number of bytes to be written at a //time.

fin.Write(inName, 0, (int)inName.Length);fin.Close();

fin= new FileStream("tempIn.dat", FileMode.Open,

FileAccess.Read);

long totlen = fin.Length;

DES des = new DESCryptoServiceProvider();

CryptoStream encStream = new CryptoStream(fout, des.CreateEncryptor(desKey, desIV),

CryptoStreamMode.Write);

Console.WriteLine("Encrypting…");

//Read from the input file, then encrypt and write to the //output file.

while(rdlen < totlen)

{

len = fin.Read(bin, 0, 100);

encStream.Write(bin, 0, len);

rdlen = rdlen + len;

Console.WriteLine("{0} bytes processed", rdlen);

}

encStream.Close();

fout.Close();

fin.Close();

fout=new FileStream("tempOut.dat", FileMode.Open, FileAccess.Read);

totlen = fout.Length;

byte[] res = new byte[(int) totlen];

fout.Read(res,0,(int)totlen);

fout.Close();

return res;

}

[WebMethod]

public string Crypt(string text, string parola)

{

DES des= new DESCryptoServiceProvider();

byte[] temp =new byte[1000];

byte[] temp2 =new byte[text.Length];

for(int i=1;i<text.Length;i++)

temp2[i]=(byte)text[i];

byte[] cheie = new byte[parola.Length];

char[] ps=parola.ToCharArray(0, parola.Length);

for (int i=0;i<parola.Length;i++)

cheie[i]= (byte) ps[i];

des.GenerateIV();

temp=EncryptData(temp2,cheie,des.IV);

string temp1 =Convert.ToBase64String(temp);

return temp1;

}

Pentru a crea Web service, executați click pe Build Solution în meniul Build.

3.3.2 Configurarea directorului virtual a serviciului Web pentru utilizarea SSL

Această procedură presupune că Dvs. deja aveți un certificat de server valid instalat pe serverul Web.

Porniți IIS pe calculatorul ce găzduiește serviciul Web.

Navigați spre directorul virtual CryptoService.

Click-dreapta a mouse-ului deasupra CryptoService, selectați Properties.

Alegeți meniul Directory Security.

Sub Secure communications, apăsați Edit. Dacă Edit nu este disponibil, atunci certificatul pe server nu este instalat.

Selectați Require secure channel (SSL).

Click OK.

În căsuța Inheritance Overrides selectați Select All, pe urmă închideți tabelul cu proprietăți a CryptoService. Aceasta aplică setările noi tuturor subdirectoarelor din directorul virtual.

3.3.3 Testarea serviciului Web folosind browser-ul

Această procedură asigură că certificatul serverului este valid și a fost emis de autoritatea de certificare care este de încredere pentru calculatorul client.

Porniți Internet Explorer pe calculatorul client și navigați(folosind HTTPS) către Web service. De exemplu:

https://WebServer/cryptoservice/crypto.asmx

Pagina de test a serviciului Web trebuie să fie afișată de browser.

Dacă pagina de test a fost afișată cu succes, închideți Internet Explorer treceți deodată la procedura 3.3.5 (Dezvoltarea aplicației Web pentru a apela Serviced Component).

Dacă apare figura Security Alert, cum e în figura 3.1, executați click pe View certificate pentru a vedea identitatea Autorității de Certificare emitente a certificatului serverului. Dvs. trebuie să instalați certificatul pe calculatorul client. Această procedură este descrisă în pasul 3.3.4 (Instalarea certificatului pe calculatorul client).

Închideți Internet Explorer.

Figura 3.1 Mesajul de alertă

3.3.4 Instalarea certificatului pe calculatorul client

Această procedură instalează certificatul emis de Autoritatea de Certificare(CA) pe calculatorul client ca certificat de încredere. Calculatorul client trebuie să aibă încredere în Autoritatea emitentă pentru a accepta certificatul fără apariția mesajului Security Alert.

Porniți Internet Explorer și accesați http://hostname/certsrv, unde hostname este numele calculatorului pe care este instalată Autoritatea de Certificare Microsoft care a emis certificatul.

Click Retrieve the CA certificate or certificate revocation list, apoi click Next.

Click Install this CA certification path

Apăsați Yes în Root Certificate Store

Apelați Web service-ul folosind HTTPS. De exemplu:

https://WebServer/Cryptoservice/crypto.asmx

Acum pagina de test ar trebui să fie afișată corect, fără Security Alert.

Acum aveți certificatul CA instalat în personal trusted root certificate store.

Repetați pașii 1 și 2, selectați Download CA certificate și salvați certificatul într-un fișier din calculatorul local.

Dacă aveți fișierul certificatului .cer atunci puteți trece la pașii rămași.

Apăsați Start și pe urmă Run.

Tapați mmc, apăsați Enter.

În meniul Console, selectați Add/Remove Snap-in.

Click Add.

Selectați Certificates, apoi Add.

Selectați Computer account, apoi Next.

Selectați Local Computer: (the computer this console is running on), apoi Finish.

Click Close, apoi OK.

Expandați Certificates (Local Computer)

Expandați Trusted Root Certification Authorities.

Click-dreapta Certificates, și, din All Tasks, selectați Import.

Click Next.

Introduceți adresa și numele fișierului .cer salvat anterior.

Click Next.

Selectați Place all certificates in the following store, apoi click Browse.

Selectați Show physical stores.

Expandați Trusted Root Certification Authorities și selectați Local Computer.

Click OK, Next, apoi Finish.

Închideți fereastra.

3.3.5 Dezvoltarea aplicației Web pentru apelarea serviciului Web

Această procedură creează o simplă aplicație Web ASP.NET. Veți folosi această aplicație ca aplicația client pentru a apela serviciul Web.

Cum să creăm o simplă aplicație Web ASP.NET

Pe calculatorul client creăm C# ASP.NET Web application numită Cryptoapplication.

Adăugați referință Web (folosind HTTPS) serviciului Web.

Click-dreapta pe nodul References din cadrul Solution Explorer, apoi selectați Web Reference

În căsuța de dialog Add Web Reference introduceți URL Web service-ului. Asigurați-vă că folosiți URL cu HTTPS.

Selectați Add Reference.

Deschideți WebForm1.aspx.cs și adăugați următorul fragment de cod la acel existent.

using Cryptoapplication.WebReference1;

Treceți WebForm1.aspx în Designer mode și creați o formă ca aceea ilustrată în figura de mai jos, folosind următoarele identificări:

text

parola

temp1

crypt

Dublu-click butonul Crypt pentru a crea handler-ul pentru evenimentul apăsării pe buton.

Adăugați următorul fragment de cod:

private void crypt_Click(object sender, System.EventArgs e)

{

Crypt Service = new Crypt();

string Result = (string) Service.Crypt( text.Text, parola.Text);

temp1.Text = Result.ToString();

}

În meniul Build, selectați Build Solution.

Porniți aplicația. Introduceți două numere pentru adunare și apăsați butonul Add. Aplicația Web va apela Web service folosind SSL.

3.4 Apelarea unui serviciu Web folosind certificatele client

Certificatele client asigură un mecanism excelent de autentificare pentru aplicațiile Web. Un browser sau o altă aplicație client trebuie să prezinte un certificat valid pentru a obține accesul la aplicație, evitând nevoia ca clientul să prezinte numele și parola. Astfel, certificatele client sunt indeosebi folositoarea când se creează servicii Web care sunt accesate de alte aplicații client.

Acest modul descrie modul de apelare a unui Web service care este configurat pentru a cere certificatele client de la aplicațiile Web.

Când se utilizează certificatele client, aplicația beneficiează de crearea unui canal securizat (folosind SSL) între aplicația client și Web service. Acest fapt permite transmiterea în siguranță informații confidențiale către și de la Web service. SSL asigură integritatea și confidențialitatea mesajului.

Utilizarea unei componente deservite

Soluția prezentată în acest modul folosește o componentă deservită configurată pentru rularea în cadrul unei aplicații server Enterpirse Services, folosind un cont propriu de service. Aplicația Web ASP.NET apelează componenta deservită, care efectuează un apel către Web service (evitând certificatul client). Configurarea acestei soluții este prezentată în figura 1.

Figura 3.2 ASP.NET apelează componenta deservită pentru a invoca Web service-ul

Această configurare asigură accesul sistemului către profilul utilizatorului în comunicarea cu Web service.

Nota: Contul ASP.NET utilizat pentru executarea aplicațiilor Web conține un privilegiu de tip "Deny interactive logon", care previne logarea interactivă pe acest cont. Ca rezultat, acest cont nu are profil de utilizator.

Nu oferiți contului ASP.NET (sau oricărui alt cont folosit pentru executarea aplicațiilor Web) capabilitatea de logare interactivă. Întotdeauna urmați principiul celui mai mic privilegiu când configurați conturile pentru executarea aplicațiilor Web și oferiți-le cât mai puține privilegii posibile.

Când se apelează un Web service ce necesită certificate client, există o întâmpinare SSL ce are loc între client și server. Câteva dintre componentele schimbate sunt certificatul server-ului, certificatul clientului și un "secret pre-master" care este generat de client. Acest secret este folosit mai târziu în protocol pentru a genera un "master secret."

Pentru ca server-ul să verifice că furnizorul certificatului este într-adevar deținătorul cheii private, clientul trebuie să cripteze secretul pre-master și să transmită acesta la server. Pentru ca sistemul să acceseze cheia privată a clientului pentru a semna secretul pre-master acesta trebuie să acceseze cheia privată din depozitul de chei a clientului. Depozitul de chei a clientului este localizat în cadrul profilului client care trebuie încărcat.

Certificatele clientului oferă un excelent mecanism de autentificare la Web service. Aceasta vă permite să trimiteți și să primiți informație confidențială către, respectiv de la Web service. SSL asigură integritatea și confidențialitatea mesajului.

Acest capitol descrie cum să apelăm un Web service ce este configurat să utilizeze certificatele client.

Cerințe:

Sistem de operare Microsoft Windows 2000

Microsoft Visual Studio .NET

Accesul la Autoritatea de certificare pentru a genera certificate noi

Un server Web cu un certificat de server instalat.

Acest exercițiu include următoarele proceduri:

Crearea unui simplu Web service

Configurarea directorului virtual pentru cererea Certificatelor Client

Crearea unui Custom Account pentru executarea componentei deservite

Cererea unui Certificat Client pentru Custom Account

Testarea certificatului client folosind browser-ul

Exportarea certificatului client către un fișier

Dezvoltarea componentelor deservite pentru apelarea Web Service

Configurarea și instalarea a Serviced Component

Dezvoltarea aplicației Web pentru apelarea componentei deservite

Notă: În acest modul calculatorul ce găzduiește serviciul Web se va numi WSServer și calculatorul ce găzduiește aplicația Web și serviced component se va numi WSClient

Crearea unui serviciu Web

Pentru a crea un Web service pe calculatorul gazdă:

Porniți Visual Studio .NET și creați o nouă aplicație C# ASP.NET Web Service numită CryptoService.

Redenumiți service1.asmx în Crypto.asmx.

Deschideți Crypto.asmx.cs și redenumiți clasa Service1 în Crypto.

Adăugați următoarea metodă Web la clasa Crypto:

using System;

using System.Collections;

using System.ComponentModel;

using System.Data;

using System.Diagnostics;

using System.Web;

using System.Web.Services;

using System.Security;

using System.Security.Cryptography;

using System.IO;

using System.Text;

namespace WebService1

{

public class crypto : System.Web.Services.WebService

{

public crypto()

{

InitializeComponent();

}

private void InitializeComponent()

{

}

private static byte[] EncryptData(byte[] inName, byte[] desKey, byte[] desIV)

{

//Create the file streams to handle the input and output //files.

FileStream fin = new FileStream("tempIn.dat",

FileMode.Create, FileAccess.Write);

FileStream fout = new FileStream("tempOut.dat",

FileMode.Create, FileAccess.Write);

fout.SetLength(0);

//Create variables to help with read and write.

byte[] bin = new byte[100]; //This is intermediate //storage for the encryption.

long rdlen = 0; //This is the total number of bytes //written.

//This is the total length of the input file.

int len;//This is the number of bytes to be written at a //time.

fin.Write(inName, 0, (int)inName.Length);fin.Close();

fin= new FileStream("tempIn.dat", FileMode.Open,

FileAccess.Read);

long totlen = fin.Length;

DES des = new DESCryptoServiceProvider();

CryptoStream encStream = new CryptoStream(fout, des.CreateEncryptor(desKey, desIV),

CryptoStreamMode.Write);

Console.WriteLine("Encrypting…");

//Read from the input file, then encrypt and write to the //output file.

while(rdlen < totlen)

{

len = fin.Read(bin, 0, 100);

encStream.Write(bin, 0, len);

rdlen = rdlen + len;

Console.WriteLine("{0} bytes processed", rdlen);

}

encStream.Close();

fout.Close();

fin.Close();

fout=new FileStream("tempOut.dat", FileMode.Open, FileAccess.Read);

totlen = fout.Length;

byte[] res = new byte[(int) totlen];

fout.Read(res,0,(int)totlen);

fout.Close();

return res;

}

[WebMethod]

public string Crypt(string text, string parola)

{

DES des= new DESCryptoServiceProvider();

byte[] temp =new byte[1000];

byte[] temp2 =new byte[text.Length];

for(int i=1;i<text.Length;i++)

temp2[i]=(byte)text[i];

byte[] cheie = new byte[parola.Length];

char[] ps=parola.ToCharArray(0, parola.Length);

for (int i=0;i<parola.Length;i++)

cheie[i]= (byte) ps[i];

des.GenerateIV();

temp=EncryptData(temp2,cheie,des.IV);

string temp1 =Convert.ToBase64String(temp);

return temp1;

}

Pentru a crea Web service, executați click pe Build Solution în meniul Build.

Configurarea directorului virtual a serviciului Web pentru utilizarea Certificatelor Digitale

Această procedură folosește Internet Information Services pentru a configura directorul virtual a serviciului Web pentru folosirea SSL și cererea certificatelor.

Această procedură presupune că deja aveți un certificat valid instalat pe Web server.

Porniți Internet Information Services pe calculatorul gazdă.

Navigați către directorul virtual Cryptoservice.

Click-dreapta Cryptoservice, apoi click Properties.

Click pe Directory Security.

În submeniul Secure Communications, apăsați Edit. Dacă Edit nu este disponibil, înseamnă că Dvs. nu aveți instalat certificat pe serverul Web.

Selectați Require secure channel (SSL).

Selectați opțiunea Require client certificates.

Apăsați OK, apoi OK.

În căsuța de dialog Inheritance Overrides apăsați Select All și apoi apăsați OK pentru a închide căsuța cu proprietăți Cryptoservice. Aceasta operațiune aplică noile setări de securitate tuturor subdirectoarelor din cadrul directorului virtual.

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

Această procedură creează un nou cont de user pe calculatorul client pe care Dvs. îl veți folosi pentru rularea componentei deservite care va apela serviciul Web.

Creați un nou cont de user cu o parolă sigură pe calculatorul client.

Adăugați contul la grupul Administrators.

Contul ce va fi folosit pentru a încărca profilul trebuie să fie administrator pe calculatorul local.

3.4.4 Cererea Certificatului Client pentru contul Custom

În această procedură, Dvs. vă veți loga pe calculatorul client folosind contul creat anterior(custom). Pe urmă veți elibera o cerere pentru certificat. Această procedură presupune că Dvs. folosiți Microsoft Certificate Services.

Această procedură presupune totodată că Microsoft Certificate Services este configurat pentru emiterea automată a certificatelor ca răspuns la cerere.

Pentru a verifica setările Microsoft Certificate Services:

Pe calculatorul pe care este instalat Microsoft Certificate Services, executați click pe Certification Authority din grupul de programe Administrative Tools.

Expandați Certification Authority(Local), click-dreapta pe autoritatea de certificare, selectați Properties.

Apăsați Policy Module, apoi Configure.

Asigurați-vă că este selectată Always issue the certificate

Obținerea certificatului client pentru contul creat:

Restartăm calculatorul și ne logăm folosind contul creat anterior. Aceasta forțează crearea profilului pentru contul custom.

Scrieți în browser adresa Autorității de Certificare. De exemplu, dacă Autoritatea este pe calculatorul numit CAServer, atunci scrieți următoarea locație:

http://caserver/certsrv

Apăsați Request a certificate, apoi click Next.

Asigurați-vă că User Certificate este selectat, apoi click Next.

Apăsați Submit. Cererea este generată și trimisă către CA pentru procesare.

După ce certificatul este emis și ați primit un răspuns de la serverul de CA, apăsați pe Install this certificate.

Asigurați-vă că certificatul emis este instalat ca certificat de încredere pe calculatorul local.

Pentru a confirma aceasta, executați următorii pași:

Apăsați butonul Start, apoi Run.

Tapați mmc, apoi click OK.

În meniul File, selectați Add/Remove Snap-in.

Click Add.

Apăsați Certificates, apoi Add.

Apăsați Computer Account, apoi Next.

Selectați Local Computer: ( the computer this console is running on), apoi Finish.

Apăsați Close și OK.

În tabelul din stânga, expandați Certificates (Local Computer).

Expandați Trusted Root Certification Authorities și selectați Certificates.

Verificați dacă certificatul este prezent în listă.

Dacă certificatul nu este în listă, urmați pașii de mai jos:

Mergeți la adresa http://caserver/certsrv.

Selectați Retrieve the CA certificate or certificate revocation list, apoi Next.

Selectați Install this CA certification path.

3.4.5 Testarea Certificatului Client folosind browser-ul

În această procedură veți apela serviciul Web ca să confirmați că nu sunt probleme și că ați făcut totul corect.

Folosiți Internet Explorer și navigați către https://server/CryptoService/Crypto.asmx. Să nu uitați să folosiți https pentru că situl este configurat să lucreze folosind SSL.

Trebuie să apară căsuța de dialog Client Authentication. Selectați certificatul client al Dvs. și apăsați OK.

Trebuie să fie afișată pagina de test a serviciului Web.

Dacă vedeți căsuța ca în figura de mai jos, trebuie să instalați certificatul autorității de certificare în Trusted Root Certification Authorities, cum e descris în procedura de mai sus.

Figura 3.3 Mesajul alertă

3.4.6 Exportarea Certificatului Client către un fișier

Această procedură exportă certificatul client către un fișier. Aceasta este cerută de serviced component, când are nevoie de a trimite certificatul Web service-ului.

Deschideți Internet Explorer. Din meniul Tools, selectați Internet Options.

Selectați submeniul Content.

Selectați Certificates.

Selectați certificatul client și apăsați Export.

Next.

Verificați dacă este selectat No, do not export the private key, și apăsați Next.

Selectați DER encoded binary X.509 (.CER) și apoi Next. Trebuie să folosiți acest format, pentru că .NET Framework nu suportă formatele Base-64 sau PKCS #7.

Introduceți numele fișierului de export. Să țineți minte locația fișierului de export .cer, pentru că veți avea nevoie curând de ea.

Apăsațti Next și Finish pentru a exporta certificatul.

Închideți Internet Explorer.

Logați-vă folosind contul Dvs. obișnuit.

3.4.7 Dezvoltarea componentelor deservite pentru apelarea Web Service

Această procedură creează o nouă aplicație C# Class Library și creează serviced component folosită pentru a apela Web service. Aceasta presupune că lucrați la calculatorul client.

Porniți Visual Studio .NET și creați proiect C# Class Library numit WebServiceRequestor.

Adăugați referință Web la Web service Cryptoservice.

Important: Trebuie temporar să reconfigurați directorul virtual al serviciuluiWeb, ca el să nu ceară certificatele client, timp cât adăugăm referința. După ce adăugați referința, reveniți la vechile setări.

În căsuța de dialog Add Web Reference, atunci când specificați locația serviciului Web să fiți atent și să puneți https. Dacă uitați aceasta, veți primi o eroare, pentru că directorul virtual al serviciului Web este configurat să folosească SSL.

Adăugați referință la System.EnterpriseServices assembly.

Redenumiți class1.cs în ProfileManager.cs

Adăugați următoarea definiție la clasa ProfileManager.cs(înlocuind carcasa clasei class1).

internal class ProfileManager

{

[DllImport("Userenv.dll", SetLastError=true,

CharSet=System.Runtime.InteropServices.CharSet.Auto)]

internal static extern bool LoadUserProfile(IntPtr hToken,

ref PROFILEINFO lpProfileInfo);

[DllImport("Userenv.dll", SetLastError=true,

CharSet=System.Runtime.InteropServices.CharSet.Auto)]

internal static extern bool UnloadUserProfile(IntPtr hToken, IntPtr hProfile);

[StructLayout(LayoutKind.Sequential, CharSet=CharSet.Ansi)]

public struct PROFILEINFO

{

public int dwSize;

public int dwFlags;

public String lpUserName;

public String lpProfilePath;

public String lpDefaultPath;

public String lpServerName;

public String lpPolicyPath;

public IntPtr hProfile;

}

Adăugați o a doua clasă numită CryptoServiceComponent.cs la proiect.

Adăugați următoarele la CryptoServiceComponent printre acele existente:

using System.Net;

using System.Web.Services;

using System.Security.Principal;

using System.EnterpriseServices;

using System.Runtime.InteropServices;

using System.Security.Cryptography.X509Certificates;

using WebServiceRequestor.WebReference1;

Adăugați următoarea definire a clasei……….

// This class calls the web service that requires a certificate.

public class CryptoServiceComponent : ServicedComponent

{

[DllImport("advapi32.dll", CharSet=CharSet.Auto, SetLastError=true)]

private extern static bool DuplicateToken(IntPtr ExistingTokenHandle,int SECURITY_IMPERSONATION_LEVEL,

ref IntPtr DuplicateTokenHandle);

[DllImport("kernel32.dll", CharSet=CharSet.Auto)]

private extern static bool CloseHandle(IntPtr handle);

// Calls the Web service that requires client certificates

// certFilepath points to the .cer file to use

// url is the Web service url

// text and parola are the parameters to pass to the //Web service

public long CallCryptoWebService(String certFilepath,

String url, string text, string parola)

{

bool retVal = false;

// Need to duplicate the token. LoadUserProfile needs a //token with

// TOKEN_IMPERSONATE and TOKEN_DUPLICATE.

const int SecurityImpersonation = 2;

IntPtr dupeTokenHandle = DupeToken(WindowsIdentity.GetCurrent().Token,

SecurityImpersonation);

if(IntPtr.Zero == dupeTokenHandle)

{

throw new Exception("Unable to duplicate token.");

}

// Load the profile.

ProfileManager.PROFILEINFO profile = new ProfileManager.PROFILEINFO();

profile.dwSize = 32;

//TODO: Replace with custom account name created in step //3.

profile.lpUserName = @"machinename\customaccountname";

retVal = ProfileManager.LoadUserProfile(dupeTokenHandle, ref profile);

if(false == retVal)

{

throw new Exception("Error loading user profile. " +

Marshal.GetLastWin32Error());

}

// Instantiate the Web service proxy

Crypt service = new Crypt();

service.Url = url;

String certPath = certFilepath;

service.ClientCertificates.Add( X509Certificate.CreateFromCertFile(certPath));

long lngResult = 0;

try

{

lngResult = service.Crypt(text, parola);

}

catch(Exception ex)

{

if(ex is WebException)

{

WebException we = ex as WebException;

WebResponse webResponse = we.Response;

throw new Exception("Exception calling method. " + ex.Message);

}

ProfileManager.UnloadUserProfile(WindowsIdentity.GetCurrent().Token, profile.hProfile);

CloseHandle(dupeTokenHandle);

return lngResult;

}

private IntPtr DupeToken(IntPtr token, int Level)

{

IntPtr dupeTokenHandle = new IntPtr(0);

bool retVal = DuplicateToken(token, Level, ref dupeTokenHandle);

if (false == retVal)

{

return IntPtr.Zero;

}

return dupeTokenHandle;

}

} // end class

În meniul Build, selectați Build Solution.

3.4.8 Configurarea și instalarea Componentei Deservite

Această procedură configurează service component, generează un nume fix, îl instalează în cache-ul global assembly și îl înregistrează cu COM+.

Deschideți assemblyinfo.cs și adăugați următorul fragment printre acele existente.

using System.EnterpriseServices;

Adăugați urmatorul nivel de atribute la assemblyinfo.cs pentru a configura componenta deservită să ruleze în cadrul unei aplicații server COM+.

[assembly: ApplicationActivation(ActivationOption.Server)]

Deschideți fereastra command prompt și deplasați-vă la directorul cu proiect.

Folosiți utilita sn.exe pentru a genera fișierul ce conține perechea de chei publică-privată.

sn.exe -k WebServiceRequestor.snk

Întorceți-vă la Visual Studio .NET.

Localizați atributul în cadrul assemblyinfo.cs și modificați cheia de referință în directorul de proiect după cum urmează:

[assembly: AssemblyKeyFile(@"..\..\WebServiceRequestor.snk")]

În meniul Build, apăsați Build Solution.

Întorceți-vă la fereastra command prompt și rulați următoarea comandă:

gacutil.exe /i bin\debug\webservicerequestor.dll

Rulați următoarea comandă pentru a înregistra assembly cu COM+:

regsvcs bin\debug\webservicerequestor.dll

Porniți Component Services (situat în cadrul Administrative Tools).

Expandați nodurile Component Services, Computers și My Computer.

Expandați mapa COM+ Applications.

Click-dreapta pe WebServiceRequestor, apoi click pe Properties.

Click pe Identity.

Selectați This user: introduceți contul și detalii corespunzătoare contului de user pe care l-ați creat ma devreme. Aceasta configurează aplicația COM+ să ruleze folosind contul dat.

Click pe OK pentru a închide fereastra cu proprietăți.

Închideți Component Services.

3.4.9 Dezvoltarea aplicației Web pentru apelarea componentei deservite

Această procedură creează o simplă aplicație Web ASP.NET pe care o veți folosi ca aplicația client ce va apela serviciul Web.

Pe calculatorul client creați C# ASP.NET Web application numită CryptoApplication.

Adăugați referință la System.EnterpriseServices.

Adăugați referință la serviced component a WebServiceRequestor. Navigați către WebServiceRequestor.dll situat în cadrul folderului bin/debug din directorul de proiect WebServiceRequestor.

Deschideți WebForm1.aspx.cs și adăugați următorul fragment de cod la acel existent.

using WebServiceRequestor;

Treceți WebForm1.aspx în Designer mode și creați o formă ca aceea ilustrată în figura de mai jos, folosind următoarele identificări:

text

parola

temp1

crypt

Dublu-click butonul Crypt pentru a crea handler-ul pentru evenimentul apăsării pe buton.

Adăugați următorul fragment de cod:

Notă: La certPath scrieți locația certificatului pe care l-ați exportat în procedura 6. Setați url cu URL-ul HTTPS al serviciului Web.

private void crypt_Click(object sender, System.EventArgs e)

{

//Înlocuiți cu adresa validă a certificatului

string certPath = @”C:\CustomAccountCert.cer”;

//Inlocuiti cu URL valid a Web service-ului

string url = https://wsserver/Cryptoservice/Crypto.asmx;

CryptoServiceComponent mathComp = new

CryptoServiceComponent();

Long Result = mathComp.CallCryptoWebService (certPath, url, text.Text,parola.Text)

temp1.Text = Result.ToString();

}

În meniul Build, selectați Build Solution.

Porniți aplicația. Introduceți două numere pentru adunare și apăsați butonul Crypt. Aplicația Web va apela Web service folosind SSL.

Concluzii:

Dacă lumea IT reușește să impună serviciile web bazate pe standarde, furnizorii de produse software vor îmbrățișa ideea de servicii web realizând produse care știu să comunice astfel cu orice alt produs indiferent de platforma pe care rulează, indiferent de cine le-a creat și indiferent cu ce tehnologie le-a construit. Ideea este extraordinară și realizabilă. În ultimii ani s-au definitivat zeci de standarde în acest domeniu și suntem în faza în care putem spune că serviciile web vor avea succes cel puțin la fel ca TCP/IP. Mai mult, pentru accelerarea standardizării și pentru oferirea unei garanții că prin serviciile web se va asigura interoperabilitatea mult dorită, s-a creat și WS-I, un organism care furnizează documente mature pentru W3C și IETF.

Lumea IT a ajuns la consens în ceea ce privește caracteristicile acelui ceva care va rezolva comunicația între aplicații. Acel ceva trebuie să fie:

independent de mașină (PC-uri, mașini mari sau dispozitive mobile), de sistemul de operare, de limbajul de programare, de baza de date sau de arhitectură,

modular,

să suporte comunicație între aplicații slab cuplate (cu gândul la internet),

utilizabile în orice domeniu, de la soluții simple P2P (Peer to Peer) la sisteme EAI (Enterprise Application Integration) și până la sisteme B2B (Business to Business) de anvergură.

Astfel, serviciile web rezolvă problema inițială – problema integrării aplicațiilor de natură diferită și construirea sistemelor informaționale distribuite. Aceasta și este diferența de bază dintre serviciile web și predecesorii săi. Cu ajutorul serviciilor web câteva, uneori total diferite, business-procese se pot integra într-un singur business-proces.

Și totuși web-services nu pot fi privite ca leac de toate business-probleme. Serviciile web, ca și multe altele, au plusurile si minusurile lor și, prin urmare, domeniile de aplicare. Necunoașterea și neconformarea în aceste domenii în proiecte reale poate duce la urmări destul de grave.

Plusurile serviciilor web sunt:

Web-services permit companiei integrarea propriilor business-procese cu business-procese ale business-partenerilor si clienților săi cu costuri mult mai mici, decât cu alte tehnologii. Costurile unor asemenea soluții este accesibilă si IMM-urilor, ceea ce va deschide companiei noi orizonturi;

Întrucât serviciile web se organizează în regiștri publici (UDDI, ebXML), accesibili persoanelor interesate din toată lumea, pragul ieșirii companiei pe piețe noi se micșoreaza, posibilitatile cresterii bazei de clienți însa, cresc.

Serviciile web asigură compatibilitatea in relația cu sisteme informationale deja existente în companie. Astfel, se păstrează investițiile făcute anterior și nu sunt necesare schimbări radicale.

Construirea soluțiilor noi cu aplicarea serviciilor web se realizează mai rapid și mai puțin costisitor.

Neajunsurile serviciilor web:

Standardele de integrare a aplicațiilor, crearea politicilor IT si business ce pot interacționa prin intermediul serviciilor web se află încă în stadiul de continuă dezvoltare și elaborare. Mai multe companii lucrează în paralel asupra serviciilor web (Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS)) de la IBM, XLANG de la Microsoft și specificațiile WS-Coordination și WS-Transaction – rezultatul colaborării IBM, Microsoft și BEA). Evident, fără formularea strictă a lor construirea sistemelor informatice pe baza tehnologiei web-service poate merge doar cu succes intermitent.

Folosirea dinamică a informațiilor din regiștrii serviciilor web, apelul serviciilor concomitent cere rezolvarea problemelor relației de încredere între diferiți regiștri. În plus, sunt probleme în utilizarea concomitentă a regiștrilor de formate diferite.

Specificația WS-Security – produsul colaborării IBM și Microsoft – este destul de “tânără” și este mereu înnoită. Se pregătesc deja specificațiile destinate securității serviciilor Web: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

Se poate observa că plusurile sunt de domeniul strategic, pe când minusurile au caracter tehnic, datorită noutății tehnologiilor serviciilor Web. Rezolvarea acestor probleme este doar o problema de timp.

Proiectul își propune asigurarea securității de comunicație dintre un serviciu Web ce execută criptarea unui text cu ajutorul algoritmului de criptare DES, o aplicație Web ce comunică cu acel serviciu Web și un browser. Realizarea securizării se face cu aplicarea protocolului SSL/TLS și cu folosirea Certificatelor Client.

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: Analiza Securitatii Serviciilor Web (ID: 149384)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

Analiza Securitatii Serviciilor Web

Copyright Notice

. Arhitecturi Lan. Standarde de Retele Locale

Infractionalitatea Grava DE Dimensiuni Transfrontaliere – Infractionalitatea Informatica

Implementarea Peoplesoft Receivables 9.0 la Ubisoft Entertainment S.a

Detectarea Regiunilor Falsificate In Imagini

Ce Este World Wide Web

CAPITOLUL 1: NOTIUNI PRIVIND APLICATIILE ERP

Copyright Notice

Similar Posts