keamanan-webservice-wcf

TINJAUAN ASPEK KEAMANANSISTEM WEB SERVICE

Tugas Akhir Semester I - 2003/2004

EC 7010 - Keamanan Sistem Lanjut

Disusun oleh :

Fx. Dwi I Rusiawan / 23202065

Program Studi Magister Teknologi Informasi - Dept. Teknik ElektroInstitut Teknologi Bandung

2003

Abstrak Web Service memberikan paradigma baru dalam mengimplementasikan sistem terdistribusi melalui Web dengan menggunakan standard protokol SOAP, WSDL dan UDDI yang berbasis XML. Dengan teknologi Web Service, konsep sistem terdistribusi yang biasanya digunakan pada sistem yang bersifat tertutup dan proprietary (DCOM, CORBA, RMI) dapat diterapkan kedalam sistem yang bersifat terbuka (non-propriertary) berbasis Web. Penerapan Web Service akan memudahkan proses integrasi dan kolaborasi antar aplikasi pada lingkungan platform yang heterogen baik melalui jaringan Intranet maupun Internet, dengan biaya yang lebih murah dan dalam waktu yang relative lebih cepat. Namun demikian, masih banyak yang ragu untuk segera menerapkan Web Service, khususnya j ika digunakan untuk mendukung transaksi bisnis melalui Internet (global) . Alasan utama yang menjadi perhatian adalah pada aspek keamanan dan kerentanan (vulnerabil ity) yang terdapat pada teknologi Web Service. Sementara itu standard keamanan yang biasa digunakan untuk mengamankan aplikasi berbasis Web pada umumnya tidak cukup mampu untuk mengamankan transaksi Web Service. Pada makalah ini dibahas berbagai aspek kerentanan dan keamanan yang ada pada Web Service, termasuk arsitektur keamanan dan spesifikasi standard keamananan untuk Web Service. Secara khusus dalam makalah ini dibahas spesifikasi WS-Security sebagai standard keamanan Web Service. Kata kunci : Web Service, XML, SOAP, WS-Security .

DAFTAR ISI Abstrak . i Daftar Isi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i i BAB I - PENDAHULUAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Permasalahan .. 1 1.2 Tujuan Penulisan .. 2 BAB II - WEB SERVICE .. 3 2 .1 Arsitektur Web Service .. 3 2 .2 Standard Teknologi Web Service .. 5 BAB III - ASPEK KERENTANAN & KEAMANAN WEB SERVICE .. 7 3 .1 Sumber Kerentanan Web Service . 7

3 .1 .1 Kerentanan pada XML . 7 3 .1 .2 Kerentanan pada SOAP . 9

3 .2 Aspek Pengamanan Web Service . 10 3.3 Serangan Keamanan pada Web Service . 12 BAB IV - ARSITEKTUR KEAMANAN WEB SERVICE .. 15 4.1 Model Arsitektur Kemanan Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Spesif ikasi Keamanan Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 BAB V - STANDARD KEAMANAN WEB SERVICE . . . . . . . . . . . . . . . . . . . . . . 19 5 .1 Spesif ikasi WS-Security .. 20 5 .1 .1 Konsep Dasar WS-Security .. 20 5 .1 .2 Mekanisme Proteksi Pesan .. 21 5 .1 .3 Security Header .. 22 5 .2 Skenario Penggunaan WS-Security .. 25 BAB VI KESIMPULAN .. 31 Daftar Pustaka

T in jauan Aspek Keamanan S is tem Web Serv ice

Tugas EC-7010 : Keamanan S i s tem Lanjut 2003 1

BAB I

PENDAHULUAN Perkembangan Internet ikut mempengaruhi evolusi perkembangan s is tem terd is t r ibusi (dis tr ibuted sys tem) , dar i s i s tem yang berdasarkan pada platform proprietary (DCOM, CORBA, RMI) menuju plat form yang lebih terbuka (Web). Momentum perkembangan in i d iawali dengan kehadiran XML (eXtensib le Markup Language) untuk mendukung per tukaran data berbasis Web secara lebih f leksibel . Keberadaan s tandard XML kemudian ikut mendorong penetapan s tandard protokol komunikasi untuk mendukung mekanisme t ransfer data pada s is tem terdis t r ibusi melalui ja r ingan Internet yang dikenal sebagai Simple Object Access Protokol (SOAP) pada tahun 1998. Pada akhirnya kedua teknologi ini (XML dan SOAP) kemudian mendasar i perkembangan ars i tektur teknologi yang memungkinkan untuk menerapkan konsep s is tem terdis t r ibusi pada jar ingan Internet berbasis Web, yang kemudian dikenal sebagai Web Service . Standard XML dan SOAP dikembangkan oleh World Wide Web Consort ium (W3C). Selanju tnya, W3C juga ter l ibat dalam pengembangan s tandard protokol dan ars i tektur untuk Web Service, sepert i WSDL (Web Service Descrip t ion Language) , termasuk s tandard teknologi kemanan untuk Web Service sepert i XML Encrypt ion , XML Signature , dls . Disamping W3C, beberapa organisasi la in saat ini juga ter l ibat dalam pengembangan s tandard untuk Web Service, sepert i Organizat ion for Advancement of Structured Information Standard (OASIS), Web Service Interoperabi l i ty Organizat ion (WS-I) , dan Liberty Al l iance Technology Group yang disponsori oleh Sun Microsystem. Web Service memil ik i keunggulan d ibanding teknologi dengan s is tem terd is t r ibusi yang sudah ada sepert i CORBA, DCOM dan RMI karena karakter is t ik Web Service yang bersi fa t terbuka, non-propriertary , loosely coupled , dan modular . Web Service dapat di implementasikan baik untuk l ingkungan internal ( Intranet) maupun untuk l ingkungan publ ik ( Internet) . Dalam l ingkungan internal , Web Service memberikan kemudahan dan solusi baru untuk mengintegrasikan berbagai platform apl ikasi yang ada dalam organisasi /perusahaan (Enterprises Appl icat ion Integrat ion/EAI ) . Dalam l ingkungan publ ik , Web Service akan memperbaruhui konsep t ransaksi berbas is Internet seper t i e-business dengan cara mengintegrasikan proses bisnis dengan par tner bisnis secara lebih mudah, sederhana dan murah. Dan secara umum, Web Service akan mengubah paradigma para pengguna maupun pengembang perangkat lunak , dar i API (appl icat ion program interface ) -based menjadi message-based . 1.1 PERMASALAHAN Walaupun Web Service menjanj ikan solusi untuk mengatasi kelemahan teknologi berbasis Web pada umumnya, namun demikian masih banyak yang merasa ragu untuk segera menerapkan Web Service, khususnya pada l ingkungan Interne t (publ ik) , misalnya untuk mendukung t ransaksi e-business . Keraguan in i disebabkan oleh faktor jaminan keamanan dar i teknologi Web Service . Survey menunjukkan



bahwa faktor keamanan merupakan masalah utama yang menjadi perhat ian dalam mengimplementas ikan Web Service. Teknologi keamanan yang biasa digunakan untuk mengatasi aspek keamanan pada sis tem berbasis Web pada umumnya, sepert i Secure socket Layer (SSL)/ Transport Secure Layer (TSL), t idak cukup memadai j ika di terapkan pada s is tem berbasis Web Service. Hal in i dikarenakan SSL/TLS menyediakan solusi kemanan dengan konteks point- to-point pada level transport layer . Sementara karakter is t ik t ransaksi Web Service, membutuhkan pengamanan dalam konteks end-to-end pada level appl icat ion layer . Teknologi Firewall yang menyediakan pengamanan pada level Network Layer juga t idak cukup memadai , karena karakter is t ik t ransaksi Web Service yang menggunakan s tandard internet (HTTP, SMTP, FTP) akan di lewatkan oleh Firewal l karena dianggap Sebagai t raf ik Internet pada umumnya ( f i rewall fr iendly) . Walaupun teknologi keamanan yang ada saat ini masih memegang peranan pent ing, namun demikian masih diper lukan suatu mekanisme keamanan pada level apppl icat ion layer yang dapat di ter ima luas oleh berbagai pihak yang ter l ibat dalam implementasi Web Service, dan mendukung aspek in teroperabi l i tas dalam mengimplementasikan Web Service. Keberadaan s tandard kemananan Web Service tersebut akan sangat mempengaruhi prospek penerapan Web Service secara luas . 1.2 TUJUAN PENULISAN Tujuan penul isan makalah ini adalah untuk memberikan t injauan umum mengenai berbagai aspek yang menyangkut keamanan dalam mengimplementas ikan s is tem Web Service, antara lain meliput i : Konsep dasar teknologi Web Service yang relat i f masih baru sehingga per lu

ada penjelasan khusus Aspek kerentanan dan keamanan dar i Web Service yang per lu diperhat ikan

dalam mengimplementasikan Web Service Model Arsi tektur Keamanan Web Service yang secara konsepsual memberi

landasan dalam mengembangkan spesi f ikasi keamanan Web Service Standard Kemanan untuk Web Service yang ada dan sedang dikembangkan saat

ini , khususnya terhadap spesif ikasi WS-Securi ty yang akan menjadi spesif ikasi int i untuk digunakan dalam mengamankan s is tem Web Service.



BAB II

WEB SERVICE Ada berbagai vers i def inis i mengenai Web Service, yang pada in t inya menggambarkan karakter is t ik dar i Web Service, yai tu antara la in sebagai ber ikut :

Merupakan appl icat ion logic yang dapat diakses dan dipubl ikasikan menggunakan s tandard Internet (TCP/IP, HTTP, Web) .

Dideskrips ikan dalam format XML. Didenti f ikasikan dengan Universal Resources Ident i f ier (URI) Bersifa t Loosely coupled, sel f -contained, modular dan terbuka (non-

proprietary)

Digunakan untuk mendukung interoperabi l i tas interaksi machine-to-machine melalui jar ingan Internet / Intranet .

Web Service dapat di implementasikan pada l ingkungan internal ( Intranet) untuk kebutuhan in tegrasi antar s is tem apl ikasi (EAI=Enterprise Appl icat ion Integrat ion) a taupun pada l ingkungan eksternal ( In ternet) untuk mendukung apl ikasi business- to-business (e-business) . 2 .1 ARSITEKTUR WEB SERVICE Konsep ars i tektur yang mendasar i teknologi Web service adalah Service Oriented Architecure (SOA). Dalam ar i tektur ini , suatu apl ikasi dimodelkan sebagai komposis i dar i sekumpulan service yang disediakan oleh suatu komponen. Lokas i keberadaan komponen tersebut dapat di temukan oleh cl ient secara dinamis, dalam ar t i t idak dinyatakan secara s ta t is te tapi menggunakan mekanisme discovery untuk mencari keberadaan komponen tersebut . Demikian pula , cl ient dapat meminta ( invoke) service tersebut secara dinamis pula . Dalam arsi tektur in i , SOA mendefinis ikan 3 peran berbeda yang menunjukkan peran dar i masing-masing komponen dalam sis tem, yai tu :

Service provider , yai tu suatu ent i tas yang menyediakan interface terhadap s is tem yang menjalankan suatu sekumpulan tugas ter tentu. Service provider dapat merepresentasikan statu ent i tas bisnis a taupun suatu komponen sof tware yang reusable .

Service requestor , yai tu suatu ent i tas yang meminta/memperoleh (dan menemukan) sof tware service dalam rangka meyelesai kan suatu tugas ter tentu atau menyediakan solusi bisn is ter tentu.

Service registry , yai tu ent i tas yang ber t indak sebagai penyimpan (reposi tory ) suatu sof tware service yang dipubl ikasikan oleh Service provider .

Peran dan in teraksi antar komponen tersebut di tunjukkan pada gambar dibawah ini :



Gambar 2 .1- Konsep Serv ice Oriented Archi tec ture

Dalam ars i tektur in i , Service dapat didef inis ikan sebagai komponen (sof tware component ) yang memil iki karakter is t ik : Dapat dideskripsikan dalam suatu bahasa formal Dapat dipubl ikasikan pada suatu regis try of service Dapat di temukan (discover) menggunakan mekanisme s tandard Dapat diminta/d iperoleh ( invoke) melalu i jar ingan Dapat dibangun bersama service la in

W3C mengi lus trasikan model SOA tersebut sebagai deskr ips i pesan yang diper tukarkan, sepert i di tunjukkan pada gamber ber ikut ini .

Gambar 2 .2- Diagram gener ik Model Serv ice Oriented Archi tec ture

. Model Arsi tektur Web Service menggunakan konsep SOA tersebut dengan sediki t perbedaan, yai tu : Web Service menggunakan Standard terbuka, yai tu : XML (eXtensible Markup

Language) sebagai bahasa untuk mendeskrips ikan data, SOAP (Simple Object Access Protocol) sebagai protokol komunikasi antar komponen , WSDL (Web Service Descr ipt ion Language) untuk mendeskt ipsikan service, UDDI (Universal Descr ipt ion, Discovery and In tegrat ion) untuk service discovery , dan HTTP sebagai t ransport layer .



Standard Web Service merupakan message-based , bukan API-based . Dalam hal ini , komunikasi antara Web Service, Service Requester dan Service Regis t ry menggunakan pesan SOAP berbasis XML.

W3C mengembangkan draf t ars i tektur Web Service yang terd ir i dar i beberapa teknologi yang sal ing berhubungan dan ber lapis sepert i digambarkan sebagai ber ikut :

Gambar 2 .3- Ars i tek tur Web Serv ice 2 .2 STANDARD TEKNOLOGI WEB SERVICE Sepert i yang di tunjukkan pada Gambar 1 .3 tersebut diatas , Web service tersusun dar i beberapa komponen s tandard berbasis XML, yai tu : SOAP, WSDL, dan UDDI. Simple Object Access Protocol (SOAP) SOAP merupakan suatu protokol berbasis XML yang digunakan untuk kebutuhan pertukaran informasi dalam suatu s is tem terdist r ibusi dan terdesentral i sasi , seper t i halnya IIOP (pada CORBA), ORCP (pada DCOM) dan JRMP (pada RMI) . Berbeda dengan RMI, CORBA dan DCOM, SOAP merupakan protokol yang bers i fa t independent terhadap platform, model pemrograman, dan t ransport protocol yang digunakan dalam proses per tukaran pesan SOAP. Pesan SOAP dapat dikir imkan melalui HTTP, SMTP maupun FTP. Pesan SOAP berbentuk sekumpulan XML Schema yang mendefinis ikan format untuk mentransmisikan pesan XML melalui jar ingan, termasuk t ipe data dan cara menstrukturkan pesan secara tepat sehingga dapat mudah dipahami o leh server a tau end-point la innya.



Pesan SOAP terdir i dar i 3 bagian, yai tu : Envelope , suatu kerangka yang mendefinis ikan apa yang ada dalam pesan

dan bagaimana pesan harus diproses ser ta menunjukkan resipien dar i message tersebut .

Header , ber is i informasi yang berhubungan dengan keamanan dan rout ing. Keberadaan Header dalam SOAP bersi fat opt ional .

Body , ber is i data yang berhubungan dengan apl ikasi ter tentu yang sedang diper tukarkan. Data di-mark-up sebagai XML dan dimasukkan dalam format yang spesi f ik yang didef inis ikan dalam XML Schema.

Standard SOAP yang dikembangkan oleh W3C vers i terakhir adalah SOAP vers i 1 .2 yang di te tapkan pada 24 Juni 2003. Web Service Description Language (WSDL) WSDL merupakan bahasa s tandard yang menyediakan mekanisme untuk mendeskripsikan Service yang disediakan oleh s is tem (Web service ) , lokasi keberadaan service tersebut dan bagaimana cara memperolehnya, secara terst ruktur dalam format XML. WSDL dapat dianalogikan sebagai IDL ( in ter face def ini t ion language) dalam CORBA dan COM. Service dedeskrips i kan sebagai koleksi dar i entry-point a tau port komunikasi . WSDL mendeskripsikan service dengan menggunakan elemen sebagai ber ikut :

Type t ipe data yang digunakan sebagai argumen dan return type Message merepresentasikan def in is i data yang di t ransmisikan Port type sekumpulan operasi yang didukung oleh satu a tu lebih endpoint Binding mendefinis ikan protokol dan format per takaran data untuk operasi

yang didef inis ikan o leh Port type Port menspesif ikasikan end-point yang digunakan untuk binding Service koleksi endpoint yang berkai tan yang disediakan oleh Web service Operat ion mendefin is ikan kemampuan yang didukung oleh servis ter tentu

Universal Descript ion, Discovery & Integration (UDDI) UDDI merupakan sekumpulan spesif ikasi yang menunjukkan regis t ry informasi mengenai Webservice. UDDI menyediakan mekanisme untuk mempublikasikan informasi mengenai bisnis dan service pada satu lokasi (reposi tory) yang dikelo la secara terpusat dan melakukan query mengenai informasi tersebut secara dinamis dan programatis . Direktory pada UDDI ber t indak sepert i Yel low Pages dimana service dikategorikan sesuai tujuan u tamanya. Direktory UDDI terdir i dar i 3 bagian, yai tu :

White pages menyediakan informasi r inci mengenai organisasi yang menawarkan service

Yellow pages mencakup pengakatagorian jenis industr i berdasarkan s tandard taxonomi industr i

Green pages mendeskripsikan inter face dan kebutuhan untuk memperoleh service , seper t i re turn type.

UDDI merupakan f i le XML Schema yang mendef inis ikan s t ruktur data mengenai karakter is t ik b isnis dan service . Deskr is i service d idef inis ikan menggunakan dokumen Type Model ( tModel) . Secara umum UDDI beris i informasi mengenai s iapa yang menyediakan service (businessEnt i ty) , Service apa yang disediakan (businessService) , d imana lokasi service tersedia (bindingTemplate) , referensi mengenai informasi bagaimana service tersebut diperoleh ( tModel) .



BAB III

ASPEK KERENTANAN DAN KEAMANAN WEB SERVICE

Pada dasarnya s is tem Web Service memil ik i kerentanan (vulnerabi l i ty ) dasar yang sama dengan s is tem berbasis Web la innya yang menggunakan protokol HTTP. Namun demikian, karena Web Service memil iki ars i tektur s is tem yang agak berbeda dengan sis tem berbasis Web lainnya, maka Web Service memil ik i kerentanan tambahan yang spesi f ik . Karentanan ini bersumber pada arsi tektur Web Service dan protokol yang digunakan, yai tu dalam hal ini adalah : SOAP (Simple Object Access Protocol ) yang berbasis XML (eXtended Mark-up Language) . 3 .1 SUMBER KERENTANAN WEB SERVICE Disamping memil iki memil iki kerentanan yang sama sepert i apl ikasi berbasis Web lainnya (HTTP), Web Service memil ik i kerentanan tambahan yang disebabkan oleh karakter is t ik teknologi yang mendasar i Web Service, yai tu XML dan SOAP. Oleh karena i tu s tandard keamanan yang biasa digunakan pada apl ikasi berbasis Web t idak cukup memadai j ika di terapkan pada Web Service. Karakter is t ik spesif ik yang menjadi sumber kerentanan pada Web Service ter le tak pada 2 hal ber ikut in i , yai tu : Protokol yang menjadi dasar teknologi Web Service , yai tu SOAP yang

berbasis XML. Arsi tektur Web Service yang memberi landasan dalam hal mekanisme

t ransaksi dan implementas i Web Service. Dalam subbab ber ikut ini per tama-tama akan dibahas mengenai kerentanan pada XML yang menjadi basis teknologi Web Service, kemudian protokol SOAP, yang juga berbasis XML, yang digunakan sebagai protokol komunikasi antara Service Request dan Service Provider .

3.1.1 Kerentanan pada XML (XML Vulnerabi l i ty ) XML (eX tensible Mark-up Language) digunakan sebagai teknologi dasar dar i Web Service berdasarkan per t imbangan bahwa XML merupakan s tandard yang terbuka dan te lah di ter ima secara luas untuk mendukung t ransaksi berbasis Internet . Dalam Arsi tektur Web Service, XML di implementasikan untuk menspesif ikasikan elemen utama Web Service, yai tu :

Communicat ion Protocol : SOAP (Simple Object Access Protocol) Service Descrip t ion : WSDL Service Publ icat ion & Discovery : UDDI.

XML merupakan bahasa gener ik untuk pertukaran data melalui Internet dan menjadi s tandard p latform komunikasi dalam sis tem yang heterogen. Tidak seper t i HTML, XML memisahkan antara bagian Data (content) dan bagaimana data di tampilkan (presentat ion) secara ters t ruktur . Oleh karena i tu , data pada XML



membuka kemungkinan untuk dapat dimanipulasi oleh s iapapun yang dapat membacanya. XML juga mudah di ter jemahkan oleh berbagai bahasa pemrograman. Karena s i fa t yang berbasis teks , mudah dibaca oleh manusia (human-readeble) , maka dokumen XML mudah untuk di-debug dan dilewatkan melalui Firewall . Suatu apl ikasi yang berbasis XML dapat mendefinis ikan markup tag untuk merepresentasikan e lemen data yang berbeda dalam suatu f i le teks sedemikian hingga data dapat d ibaca dan diproses oleh apl l ikasi yang menggunakan XML. Dengan menggunakan XML, suatu ent i tas bisnis dapat mendefinis ikan suatu pol icy dan mengekspresikannya dalam dokumen XML.

Gambar 3 .1- Contoh WSDL berbas is XML

Dengan karakter is t ik yang berbasis teks dan bers i fa t terbuka tersebut , maka kelemahan pada XML ini juga dapat menjadi sumber kerentanan pada apl ikasi berbasis Web Service dengan membuka peluang adanya gangguan atau serangan (attack ) terhadap keamanan dokumen WSDL, UDDI dan protokol SOAP yang berbasis XML. W3C dan OASIS te lah menetapkan standard untuk menangani kerentanan XML, yai tu antara la in : XML Signature, XML Encrypt ion, dan SAML. Pembahasan selengkapnya mengenai s tandard SAML ini akan diber ikan pada Bab II I , sementara XMLSignature dan XML Encrypt ion sudah dibahas pada laporan tugas akhir yang sudah ada sebelumnya.



3.1.2 Kerentanan Pada SOAP SOAP merupakan s tandard protokol komunikasi untuk per tukaran informasi dalam sis tem Web Service . Pada umumnya pesan SOAP dikir im melalui protokol HTTP. Namum demikian pada dasarnya SOAP merupakan protokol yang independen terhadap layer t ransport . Dengan kata lain , pesan SOAP juga dapat dikir im melalu i SMTP, atau FTP. Dalam satu t ransaksi Web Service, suatu pesan SOAP dapat ber jalan melalui layer t ransport yang berbeda-beda, misalnya, pada tahap per tama menggunakan HTTP, kemudian di teruskan melalui SMTP, dan seterusnya. Pada apl ikasi berbasis Web, bisanya digunakan s tandard pengamanan Secure Socket Layer/Transport Secure Layer (SSL/TSL) untuk mengamankan t ransaksi melalui HTTP. SSL memberikan jaminan conf ident ial i ty melalui mekanisme enkripsi dan jaminan otent ikasi menggunakan set i f ikat digi ta l X.509 untuk sesi HTTP yang bersifat tunggal dan point- to-point . Namun demikian, SSL t idak dapat menyediakan mekanisme audi t trai l yang dapat menjamin bahwa sesi tersebut ada a tau pernah ter jadi .

Gambar 3 .2- Model kemanan dengan konteks point- to-point

Oleh karena i tu , solusi terhadap kelemahan dari SSL in i adalah dengan cara menerapkan mekanisme pengamanan pada pesan SOAP i tu sendir i , bukan hanya pada layer t ransport dimana pesan SOAP diki r im. Solusi ini menjamin bahwa j ika SOAP dikir im melalu i ja lur t ransport yang t idak aman, a tau j ika pesan SOAP harus dikir im melalui beberapa layer t ransport yang berbeda-beda dan dalam l ingkungan yang t idak aman, pesan SOAP tersebut dapat te tap di jamin aman. Misalnya, j ika digunakan analogi antara SOAP dan Email . J ika Email dik ir im melalui Internet , maka t idaklah cukup j ika hanya meng-enkrip l ink antar Mail server , untuk i tu pesan Email i tu sendir i juga per lu d i-enkrip. Demikian juga halnya dengan pesan SOAP. OASIS te lah mengembangkan s tandard untuk mengamankan pesan SOAP ini dengan nama WS-Security yang akan dibahas pada Bab III . Pada s is i la in , dalam Web Service, pesan SOAP d i-generate o leh apl ikasi , bukan oleh manusia/orang. Akan te tapi keputusan untuk pengamanannya te tap didasarkan pada ident i tas orang yang melakukan t ransaksi . Misalnya dalam si tuasi dimana Web Service digunakan pada kasus pengadaan barang, dimana seorang buyer masuk ke suatu Portal Pengadaan Barang dengan mengotent ikasi d ir inya menggunakan password untuk membuat Purchase Order request . Pesan SOAP kemudian dikir im ke beberapa Suppl ier a tas nama Buyer tersebut . Suppl ier menggunakan mekanisme pengamanan layer t ransport untuk meng-otent ikasi pengir im pesan SOAP tersebut , dalam hal ini Porta l Pengadaan Barang. J ika Suppl ier ingin mengetahui s iapa ident i tas Buyer yang mengir im Purchase Order request tesebut , apa yang harus di lakukan ? Mekanisme pengamanan layer t ranspor t seper t i SSL t idak dapat melakukan kebutuhan demikian. Oleh karena i tu konteks keamanan harus dapat dapat menjamin mekanisme pengamanan end-to-end , d imulai dar i end-

SSeeccuurr ii tt yy CCoonntteexx tt

Service Service ProviderIntermediary




user yang melakukan otent ikasi menggunakan password (dalam contoh tersebut adalah Buyer ) sampai dengan Web Service yang bekerja a tas nama end-user dengan menggunakan pesan SOAP.

Gambar 3 .3- Model kemanan dengan konteks end- to-end

Dalam hal ini , mekanisme keamanan di terapkan dengan menyisipkan informasi mengenai ident i tas user (securi ty in formation ) d idalam pesan SOAP. Informasi tersebut mencakup antara la in : s ta tus otent ikasi dar i end-user (dalam kasus ini adalah Buyer) , akt iv i tas yang diperbolehkan (o tor isasi) , dan atr ibut la in mengenai user tersebut yang berguna untuk menetapkan access control . OASIS te lah menetapkan s tandard untuk maksud tersebut dengan nama SAML (Securi ty Asser t ion Markup Language) yang menspesif ikasikan bagaimana informasi mengenai ident i tas user tersebut didef inis ikan dalam dokumen XML sebagai pernyataan (assert ion ) mengenai user . Sementara i tu WS-Securi ty mendefin is ikan bagaimana pernyataan tersebut d i tempatkan dalam pesan SOAP. Pembahasan mengenai s tandard ini akan dibahas pada Bab II I . 3.2 ASPEK PENGAMANAN WEB SERVICE Secara umum ada 5 aspek keamanan dasar yang per lu diperhat ikan dalam mengimplementas ikan s is tem berbasis Web pada umumnya termasuk dalam hal in i adalah apl ikasi Web Service , yai tu : Authent icat ion , Authorizat ion , Confident ial i ty , Data Integri ty dan Non-Repudiat ion . Disamping i tu layanan apl ikasi berbasis Web harus dapat memberikan konteks pengamanan secara end-to-end , d imana set iap t ransaksi harus dapat di jamin keamanannya mulai dar i asa l t ransaksi sampai dengan penyelesaian akhir t ransaksi sehingga dapat mempertahankan keamanan yang konsis ten di semua tahapan pengolahan t ransaksi . Otentikasi Otentikasi (Authent icat ion ) merupakan proses untuk mengident i f ikasi Pengir im mupun penerima. Sepert i halnya apl ikasi berbasis Web la innya, Service requester per lu di-o tent ikasi o leh service provider sebelum informasi dikir im. Sebal iknya, Service requester juga per lu meng-otent ikasi Service provider . Otent ikasi sangat pent ing dan crucial d i terapkan untuk melakukan t ransaksi di In ternet . Saat ini te lah tersedia s tandard yang biasa digunakan untuk menerapkan mekanisme Otent ikasi pada apl ikasi berbasis Web pada umumnya, yai tu antara la in PKI, X.509 Cert i f icate , Karberos, LDAP, dan Active Directory . Dalam kai tannya dengan Web Service, dokumen WSDL dapat dirusak melaluj i serangan spoof ing sedemikian hingga Service requester berkomunikasi bukan dengan Service pr ivider sesungguhnya, melainkan


Service Service ProviderIntermediary



dengan Spoofed Web Service . Oleh karena i tu , dokumen WSDL perlu di-otent ikasi untuk menjamin in tegri tas data .

Gambar 3 .4- Mekanisme Spoof ing terhadap WSDL Otorisasi Otorisasi (authorizat ion ) menjamin bahwa requester yang te lah berhasi l melakukan otent ikasi dapt meng-akses sumber daya yang ada sesuai dengan karakter is t ik akses (access control ) yang disediakan. Aplikasi berbasis Web perlu melindungi data f ront-end maupun back-end dan sumber daya s is tem lainnya dengan menerapkan mekanisme kontrol akses , sebagai contoh : apa yang dapat di lakukan oleh user /apl ikasi , sumber daya apa yang dapat d iakses , dan operasi apa yang dapat di lakukan terhadap data tersebut . Confidencial i ty Confident ial i ty menjamin kerahasiaan (privacy) terhadap data/ informasi yang diper tukarkan yai tu dengan melindungi data/ informasi agar t idak mudah dibaca oleh ent i tas (orang atau apl ikasi) yang t idak berhak. Standard yang biasa digunakan untuk menjaga kerahasiaan data yang dikir im adalah menggunakan teknologi Enkripsi , misalnya dengan metode Digi tal Signature . Service requester menandatangani dokumen yang dikir imkan dengan suatu private key , dan mengir imkannya bersamaan dengan body of message . Service provider kemudian dapat memverif ikasi tandatangan tersebut dengan senders pr ivate key untuk melihat apakah ada bagian dar i dokumen yang te lah berubah. Dengan cara ini , s is tem dapat menjamin integri tas data ket ika melakukan komunikasi satu sama la in . Integritas Data Integri tas data menghendaki bahwa komunikasi antara c l ient dan server di l indungi dar i adanya kemungkinan untuk merubah data oleh user /apl ikasi yang t idak memil iki hak untuk melakukan perubahan data. Dengan kata la in , Integri tas Data menjamin bahwa data t idak berubah selama proses pengir iman data dar i sumber ke tujuan. Standard yang biasa digunakan untuk mengamankan ja lur komunuikasi berbasis Internet adalah Secure Socket Layer/Transport Layer Securi ty (SSL/TSL) dengan menggunakan protokol HTTPS. Seper t i suda di jelaskan tersebut dia tas , SSL/TSL memil ik i konteks keamanan yang bersi fat point- to-point antara Service requestor dan Service provider . Akan te tapi dalam banyak hal , service provider bukan tujuan f inal dar i pesan yang dikir imkan. Service provider dapat ber t indak sebagai Service



requestor yang mengir imkan pesan ke berbagai Service provider la innya, seper t i digambarkan sebagai ber ikut .

Gambar 3 .5- Model Transaks i da lam Web Serv ice

Untuk mengamankan mekanisme t ransaksi sepert i tersebut dia tas , d ibutuhkan mekanisme keamanan dengan konteks end-to-end securi ty , yai tu dengan menggunakan s tandard XML Encrypt ion dengan cara meng-enkrip sebagian dar i format pesan, d imana bagian payload dar i pesan d i -enkrip , sedang bagian Header digunakan untuk kebutuhan rout ing. Non-Repudiation. Non-repudiat ion menjamin bahwa masing-masing pihak yang ter l ibat dalam t ransaksi (cl ient & service provider ) t idak dapat menyangkal ter jadinya t ransaksi yang te lah di lakukan. Mekanisme in i dapat d i lakukan dengan menggunakan teknologi digi tal s ignature dan t imestamping . Dengan teknologi dig i ta l s ignature , Sevice provider t idak hanya memberikan bukt i bahwa te lah ter jadi t ransaksi , te tapi juga merekam tranksaksi pesan kedalam audi t log yang te lah d i tandatangani pula. Sekal i audi t log te lah di tandatangani , ia t idak dapat dimodif ikasi (oleh Hacker) tanpa merubah tandatangan secara s ignif ikan. 3.3 SERANGAN KEAMANAN PADA WEB SERVICE Salah satu kunci kesederhanaan Web Service adalah bahwa Web Service di impelementasikan pada port 80 dan 443, sama sepert i s tandard apl ikasi berbasis Web lainnya. Keuntungannya adalah dapat menyerdehanakan komunikasi antara beberapa ent i tas , te tapi dis is i la in memil iki kelemahan dengan membuka peluang munculnya gangguan keamananan yang kurang dimengert i sebelumnya. Untuk mengatasinya, biasanya digunakan Firewal l yang dapat melakukan tugas seper t i port monitoring dan mengenal i adanya serangan yang bers i fa t brute force , akan tetapi Firewal l t idak dapat melakukan tugas untuk melihat is i pesan sebagai upaya untuk mendeteksi dan mencegah adanya gangguan keamanan yang yang lebih kompleks. Pada s is i la in, Fi rewall t idak dapat memberikan proteksi terhadap serangan yang berasal dar i dalam ( internal ) perusahaan i tu sendir i , seper t i yang di tunjukkan pada gambar ber ikut ini .



Gambar 3 .6 Contoh implementas i Keamanan Web Serv ice dengan meggunakan Firewal l

F i rewall dapat mengenal i pesan SOAP, tetapi menganggapnya hanya sebagai t raf ik normal biasa seper t i t raf ik HTTP pada umumnya. Walaupun demikian Firewal l juga dapat diatur (conf igure) untuk menolak atau mengij inkan t raf ik SOAP. SOAP interface merupakan perangkat lunak yang memil iki format Applicat ion Program Interface (API) dan dapat menjalankan berbagai macam fungsi . Misalnya, suatu apl ikasi Web Service dapat terdi r i dar i ra tusan atau r ibuan operasi yang dapat di lakukan, semuanya melalui port 80. Semetara i tu dokumen WSDL dan is i UDDI menyediakan informasi r inci yang memberi peluang untuk Hacker untuk mel ihat is inya karena karakter is t ik XML yang bersifat (sel f -describing) dan secara je las menunjukkan elemen data . Beberapa jenis serangan yang mungkin ter jadi terhadap apl ikasi berbasis Web juga bisa ter jadi pada apl ikasi Web Service, yai tu antara lain adalah Denial of Service (DOS), Buffer Overf low, Reply Attack, dan Dict ionary Attack.

Gambar 3 .7- Jenis gangguan kemanan pada Web Serv ice

Denial Of Service Contoh serangan yang bers i fa t denial o f service (DOS) ini misalnya pada kasus dimana suatu appl ikasi Web Service hanya mampu mener ima t ransaksi perse tujuan pinjaman uang sebanyak 5 permintaan sehar i , te tapi suatu serangan DOS dapat ter jadi j ika ada 10 permintaan penjaman per jam yang dikir im untuk diproses oleh s is tem. Serangan DOS biasanya akan menyebabkan kelumpuhan s is tem karena kekurangan sumber daya untuk melayani request yang masuk akibat DOS, yang dapat berakibat berhent inya operasi s is tem.



Buffer Overflow Serangan buf fer overf low pada Web Service ter jadi j ika ada parameter data yang dikir im lebih panjang dar i pada yang bisa di tangani oleh s is tem yang menyebabkan s is tem mengalami crash, a tau s is tem menjalankan kode yang t idak d ikehendaki (undesired code) yang dikir im oleh penyerang. Metode untuk melakukan ini biasanya d i lakukan dengan cara mengir imkan password dengan jumlah karakter lebih panjang dar i yang diharapkan. Serangan yang sama dengan buffer overf low adalah dikenal sebagai format s tr ing at tack , yang berupa pengir iman s t r ing atau karakter yang t idak memil ik i fungsi sepert i tanda pet ik , tanda kurung, a tau wildcard. Reply Attack Reply at tck di lakukan dengan menyal in pesan yang val id kemudian mengir imkan ke Web Service server secara berulang-ulang, seper t i halnya DOS. Untuk menangani serangan ini dapat menggunakan metode yang sama dalam menghadapi DOS. Dalam beberapa kasus, Reply at tack lebih mudah di teksi o leh Web Service karena payload pesan dapat dengan mudah dibaca. Dengan bantuan tool yang tepat , pola serangan Reply at tack dapat di teksi secara mudah walaupun j i ra serangan dikir imkan melalui berbagai medium sepert i HTTP, HTTPS, SMTP, a tau melalui berbagai interface yang berbeda. Dictionary Attack Dict ionary at tack ter jadi j ika seorang hacker menyerang dengan cara mencoba memasukkan user ID dan Password untuk masuk ke s is tem atau berbagai s is tem secara manual atau otomatis (programmatical ly ) . Oleh karena i tu seorang Administ ra tor harus dapat meyakinkan bahwa password t idak mudah di tebak dan selalu diperbaruhui /dirubah secara per iodik .



BAB IV

ARSITEKTUR KEAMANAN WEB SERVICE Model ars i tektur keamanan Web Service menekankan pent ingnya memanfaatkan proses dan teknologi keamanan yang ada saat ini dengan mengant is ipasi kebutuhan keamanan apl ikasi untuk masa mendatang. Model ini menghendaki adanya perhat ian terhadap beberapa isu , yai tu : menyatukan berbagai konsep mengenai keamanan, solusi teknologi (misalnya secure messaging) , proses bisnis (dalam terminologi policy, r isk , t rust) , ser ta koordinasi antara berbagai pihak yang ter l ibat , an tara la in : vendor , appl icat ion developer , network/ infratructure provider , dan customer. Model ars i tektur yang dibahas dalam bab ini berdasarkan usulan dar i Microsoft dan IBM dalam Securi ty in a Web Service World : A Proposed Archi tecture and Roadmap, Apri l 7 , 2002, Versi 1 .0 . Penyatuan l ingkup teknologi keamanan yang ada saat ini dimaksudkan untuk memisahkan antara kebutuhan keamanan suatu apl ikasi dengan mekanisme teknologi yang digunakan. Tujuannya adalah untuk memudahkan customer dalam membangun suatu so lusi yang sal ing dapat dioperasikan ( in teroperable ) dalam suatu l ingkungan yang heterogen. Proses integrasi di lakukan dengan membuat abstraksi terhadap suatu model keamanan ter tentu yang memungkinkan suatu organisasi menggunakan investasi teknologi keamanan yang ada saat ini untuk berkomunikasi dengan organisasi /perusahaan la in yang menggunakan teknologi yang berbeda. Pada s is i la in , set iap Web Service mempunyai kebutuhan aspek kemananan yang unik didasarkan pada kebutuhan b isnis dan l ingkungan operasional yang khusus. Misalnya, untuk kebutuhan internal , maka kesederhanaan dan kemudahan operasional merupakan tuntutan u tama, sementara untuk kebuthan eksternal ( Internet) dibutuhkan kemampuan untuk ber tahan terhadap, misalnya, serangan DOS. Untuk mendukung kebutuhan demikian maka suatu model keamanan Web Service menghendaki adanya f leksib i l i tas dalam menggunakan mekanisme keamanan konvensional , te tapi d is is i la in dapat memberikan solusi bagi berbagai macam kebutuhan keamanan sis tem melalui penerapan kebi jakan keamanan (securi ty pol icy) dan perubahan konfiguras i s is tem. Dengan kata la in , model ars i tektur kemanan Web Service merupakan sekumpulan abstraksi keamanan yang menyatukan teknologi yang berbeda-beda yang te lah ada sebelumnya. Model ars i tektur demikian dapat memenuhui kebutuhan customer yang spesif ik te tapi pada saat yang sama memungkinkan teknologi untuk terus berkembang dan dapat d i implementas ikan secara ber tahap. Sebagai contoh, suatu Web Service dapat menerapakan model secure messaging (melalui enkr ipsi terhadap pesan) ket ika mengir im pesan melalui l in tasan yang aman dengan menggunakan mekanisme keamanan berbasis transport layer (SSL/TSL) yang sudah ada. Sehingga pesan dapat memil iki aspek integri tas (a tau conf ident ial i ty ) yang ada di luar t ransport layer . 4.1 MODEL ARSITEKTUR KEAMANAN WEB SERVICE Web Service dapat diakses dengan mengir imkan pesan SOAP ke service end-point yang di ident i f ikasikan dengan URI (Unif ied Reaources Ident i f ier) , untuk meminta akt ivi tas ter tentu pada Web Service, dan kemudian menerima respon pesan SOAP (termasuk adanya indikasi adanya kesalahan, j ika ada) . Dalam konteks in i , tujuan pengamanan Web Service dibagi dalam beberap sub-goal yang menyediakan fasi l i tas untuk mengamankan integr i tas dan conf ident ia l i ty pesan dan menjamin



service hanya akan melakukan perker jaannya sesuai dengan is i pesan yang merupakan ekspresi dar i Claim yang dibutuhkan oleh suatu Pol icy . Fungsi pengamanan terhadap integri tas dan conf ident ial i t i ty pesan dapat di terapkan menggunakan teknologi SSL/TSL maupun IPSec. Namun demikian SSL/TSL maupun IPSec hanya menyediakan konteks keamanan yang bers i fa t point- to-point . Model ars i tektur Web Service yang komprehensif membutuhkan mekanisme keamanan dengan konteks end- to-end . Model ini menghendaki adanya pengamanan pada layer t ransport maupun apl ikasi . IBM dan Microsoft mengusulkan suatu model ars i tektur keamanan Web Service untuk memenuhi kebutuhan tersebut diatas dengan suatu karakter is t ik sebagai ber ikut : Web Service menghendaki bahwa set iap pesan yang masuk dapat menunjukkan

dir inya sebagai sekumpulan cla im (misalnya: nama, key, permission , kapabi l i tas , dls) . J ika suatu pesan datang tanpa memil iki claim yang dibutuhkan, maka Web Service dapat menolak atau menerima pesan tersebut . Sekumpulan claim dan informasi yang berkai tan dengannya disebut sebagai Policy .

Suatu requester dapat mengir im pesan dengan menunjukkan bukt i mengenai claim yang dibutuhkan Web Service dengan menyertakan Securi ty token bersama dengan pesan tersebut . Jadi , pesan meminta t indakan ter tentu kepada service dan membuktikan bahwa pengir im pesan memil iki claim yang meminta t indakan tersebut .

Jika requester t idak memil iki cla im yang dikehendaki , requester a tau seseorang yang mengatasnamakannya dapat mencoba memperoleh claim yang diper lukan dengan mengkontak Web Service la in . Web Service ini , yang disebut sebagai Securi ty Token Service , dapat menghendaki sekumpulan claim . Securi ty token service ber t indak sebagai perantara trust antara berbagai trust domain yang berbeda dengan menyertakan Securi ty token .

Model tersebut di i lustras ikan pada gambar dibawah ini , dimana set iap Requester dapat menjadi Securi ty Token Service , dan Securi ty Token Service dapat menjadi Web Service, yang mengekspresikan Policy dan menghendaki Securi ty token .

Gambar 4 .1 - Model gener ik secur i ty messag ing pada Web Serv ice Model generik messaging tersebut , yai tu c la im, pol icy dan securi ty token, mendukung beberapa model yang lebih spesif ik la innya seper t i halnya ident i ty-based securi ty , access-control l i s t , dan capabil i t ies-based securi ty . Model ini juga mendukung teknologi yang ada saat ini seper t i X.509 dan Karbero.



4.2 SPESIFIKASI KEAMANAN WEB SERVICE Spesif ikasi Keamanan Web Service terdir i dar i sekumpulan spesif ikasi terpisah yang dikembangkan secara hi rark is dan berlapis diatas protokol SOAP. Masing-masing spesif ikasi dikembangkan berdasarkan spesi f ikasi yang lain . Spesif ikasi awal keamanan Web Service terdir i dar i :

Message Securi ty Model Web Service Endpoint Pol icy Trust Model Privacy Model

IBM dan Microsoft memberi nama masing-masing spesif ikasi tersebut adalah WS-Security (untuk message securi ty model ) , WS-Policy (untuk Web Service end-point pol icy) , WS-Trust (untuk Trust model) dan WS-Privacy (untuk Privacy model) . Secara bersama spefikasi awal tersebut menyediakan landasan untuk menetapkan keamanan yang interoperable antar trust domain . Berdasarkan spesi f ikasi awal tersebut , kemudian dapat dikembangkan spesif ikasi ber ikutnya yai tu secure conversat ion (WS-SecureConversat ion) , federated t rust (WS-Federat ion) , dan otor isasi (WS-Authorizat ion) . Struktur kerangka spesif ikasi keamanan Web Service di i lustrasikan sepert i gambar dibawah ini .

Gambar 4 .2 Ars i tek tur & Roadmap Spes i f ikas i Keamanan untuk Web Serv ice

Kombinasi spesif ikasi keamanan tersebut memungkinkan adanya banyak skenario yang akan sul i t di implementasikan j ika menggunakan mekanisme keamanan dasar yang ada saat ini . Secara r ingkas , spesi f ikasi keamanan tersebut dapat di jelaskan sebagai ber ikut : Spesi f ikasi Awal

WS-Securi ty : Menje laskan bagaimana menerapkan XML signature dan XML Encrypt ion pada Header pesan SOAP, ser ta bagaimana menyertakan securi ty token , termasuk X.509, Karbero dan User Name/Password, kedalam pesan SOAP.

WS-Policy : menje laskan kemampuan dan kendala dar i securi ty pol ic i pada level in termediate maupun end-point .

WS-Trust : menjelaskan bagaimana framework t rustu re la t ionship antar ent i tas bisnis



WS-Privacy : menjelaskan suatu model bagaimana Web Service dan requester menyatakan pr ivasi subyek yang di inginkan dan pr ivasi organisasi .

Spesi f ikasi berikutnya

WS-SecureConversat ion : menjelaskan bagaimana mengelola dan memelakukan otent ikasi per tukaran pesan

WS-Federat ion : menjelaskan bagaimana mengintegrasikan berbagai mekanisme manajemen ident i tas

WS-Authorizat ion : menjelaskan bagaimana data otor isasi dan authoriza t ion pol icy .



BAB V

STANDARD KEAMANAN WEB SERVICE Kerentanan yang ada pada Web Service yang berbasis XML menjadi per t imbangan utama yang mempengaruhui keragu-raguan para pengguna untuk mengimplementas ikan Web Service. Oleh Karena i tu diper lukan s tandard teknologi keamananan Web Service untuk mendukung keamanan penerapan Web Service secara luas . Walaupun demikian, s tandard yang ada saat ini seper t i LDAP, PKI, SSL/TSL tetap memegang peranan pent ing untuk mengamankan Web Service dalam konteks point- to-point . Beberapa lembaga/organisasi prof i t maupun non-profi t te lah berupaya untuk mengembangkan s tandard keamanan XML dan Web Service . Diantara lembaga/organisasi tersebut , hingga saat ini ada 2 lembaga yang menjadi referensi dalam penetapan s tandard keamanan XML Web Service yai tu W3C dan OASIS. Tabel ber ikut ini menunjukkan beberapa s tandard keamanan XML Web Service yang te lah dan sedang di te tapkan oleh kedua organisasi tersebut [10] :

Standard

Standard Body

Status

Deskripsi

XML Digi ta l Signature (XDSIG)

W3C Completed Protokol untuk menandai is i dokumen digi ta l . Memberikan aspek integri tas data , dan non-repudia t ion

XML Encrypt ion (XENC)

W3C Completed Protokol untuk mengeng- kr ipsi dan dekripsi is i dokumen digi ta l .

XML Key Management Specif icat ion (XKMS)

W3C Working Draft

Protokol untuk mendis t r i busikan dan me-regis t rasi publ ic key

Securi ty Asser t ion Markup Language (SAML)

OASIS Open Standard

Menyediakan kerangka XML untuk Web Service yang mendukung per tukar an otent ikasi dan otor isasi informasi antara par tner bisnis

Extensible Access Control Markup Language (XACML)

OASIS Open Standard

Spesif ikasi XML untuk mengekspres ikan Pol icy tentang akses informasi melalui Internet .

WS-Securi ty OASIS Working Draft

Sekumpulan s tandard untuk mengamankan pesan SOAP pada aspek in tegri ty dan conf ident ia l- l i ty

Dalam bab in i fokus pembahasan hanya pada s tandard WS-Securi ty yang menjadi referensi pent ing bagi penerapan XML Web Service, dengan per t imbangan sebagai ber ikut :



WS-Securi ty akan menjadi referensi s tandard keamanan Web Service oleh berbagai pihak (user , vendor, organisasi la innya) .

WS-Securi ty t idak menspesif ikasikan s tandard keamanan ter tentu yang berbeda, te tapi memanfaatkan berbagai s tandard keamanan lain , seper t i X.509, Karberos, XML Digi ta l Signature , XML Encrypt ion, SAML, XKMS, dls .

WS-Securi ty independent terhadap teknologi keamanan pada layer t ransport . Standard keamanan pada level t ransport seper t i SSL/TLS, Karberos, X.509, LDAP, dls sudah banyak dibahas pada berbagai l i terature yang membahas keamanan apl ikasi berbasis Web pada umumnya, sehingga t idak dibahas secara detai l dalam bab ini .

WS-Securi ty merupakan implementas i dar i model arsi tektur keamanan Web Service seper t i yang dibahas pada Bab III .

5.1 SPESIFIKASI WS-Security WS-Securi ty atau juga dikenal sebagai Web Service Securi ty Core Language (WSS-Core) merupakan spesif ikasi keamanan Web Service yang mendefin is ikan mekanisme pengamanan pada level pesan SOAP untuk menjamin message integri ty & conf ident ial i ty . Standard WS-Securi ty saat in i d ikembangkan secara resmi oleh OASIS berdasarkan spesif ikasi yang d iusulkan oleh Microsoft , IBM, dan VerySign pada 11 Apri l 2002. Selanjutnya, OASIS melalu i Web Service Securi ty Technical Commit tee (WSS) melanjutkan pengembangan WS-Securi ty dengan menetapkan beberapa spesi f ikasi teknis terpisah, sepert i Core Specif icat ion , SAML Profi le , XMrL Profi le , X.509 Prof i le , dan Karberos Prof i le . Produk WSS untuk Core Speci f icat ion (WSS-Core) adalah WSS: Soap Message Securi ty . Spesif ikasi la in yang merupakan bagian dar i Core Speci f icat ion ini adalah WSS: User Name Token Prof i le dan WSS: X.509 Cert i f icate Token Prof i le . Disamping 2 organisasi tersebut , ada organisasi la in yang juga akt i f mengembangkan s tandard keamanan Web Service yang disponsori oleh Sun Microsystem yai tu Liberty Al l iance Technology Group . Namun pada akhirnya lembaga ini juga mengumumkan untuk memfokuskan dir i pada pengembangan spesi f ikasi WS-Securi ty dan berkerjasama dengan OASIS untuk maksud tersebut . Dengan demikian, WS-Securi ty akan menjadi s tandard de-facto untuk pengamanan Web Service. 5.1.1 Konsep dasar WS-Securi ty Secara umum standard WS-Securi ty (vers i or is inal) mendefin is ikan suatu spesi f ikasi mengenai bagaimana mengamankan pesan SOAP secara end-to-end , dengan cara menyertakan (attach ) digi tal s ignature , enkripsi dan securi ty token pada bagian Header dar i pesan SOAP. Spesi f ikasi WSS-Core vers i terbaru menyediakan 3 mekanisme untuk memproteksi pesan dar i ancaman terhadap upaya gangguan keamanan pesan SOAP, yai tu (1)Kemampuan untuk mengir im securi ty token sebagai bagian dar i pesan SOAP, (2) Message integr i ty dan (3) Message confident ia l i ty . Namun demikian, mekanisme tersebut t idak memberikan solusi keamanan yang lengkap untuk Web Service. Spesif ikasi in i merupakan bui lding block yang digunakan untuk mengakomoda- s ikan berbagai var ias i model keamanan dan teknologi kemanan. Dengan kata lain , WS-Securi ty t idak menspesif ikasikan suatu mekanisme keamanan baru, te tapi menyediakan f leksibi l i tas untuk menggunaan teknologi keamanan yang sudah ada (X.509, Karberos, XML Encrypt ion) , sehingga dapat



mengakomodasi berbagai pendekatan keamanan secara umum. Hal baru yang di tambahkan oleh WS-Securi ty adalah suatu spesif ikasi untuk menerapkan mekanisme keamanan yang sudah ada (exis t ing ) tersebut kedalam pesan SOAP. 5.1.2 Mekanisme Proteksi Pesan Secara umum struktur pesan Format SOAP yang mengimplementasikan WS-Securi ty terdi r i dar i : Envelop , Header dan Body seper t i d igambarkan sebagai ber ikut :

Gambar 5 .1- Diagram Struktur Pesan SOAP Spesif ikasi keamanan Web Service d i terapkan pada bagian Header dan/atau Body dari pesan SOAP. WSS-Core menspesif ikasikan model keamanan pesan dalam dalam bentuk securi ty token yang digabung dengan teknologi digi tal s ignature untuk melindungi dan meng-otent ikasi pesan SOAP. Securi ty Token menyediakan mekanisme untuk membuktikan informasi mengenai key dar i Pengir im. Namun demikian, spesif ikasi in i t idak mendefinis ikan metode khusus untuk melakukan otent ikasi , te tapi hanya menunjukkan bahwa securi ty token dapat d i terapkan dalam pesan SOAP. Deklarasi securi ty token dapat disyahkan oleh Otorisator a taupun t idak per lu d isyahkan. Securi ty token yang per la pengesahan disebut signed securi ty token . Contoh penggunaan signed securi ty token adalah X.509 Certif icate dan Karberos . Secur i ty token yang t idak per lu pengesahan (unsigned secur i ty token) memerlukan mekanisme untuk menolak atau menerima pesan bersarkan kepercayaan pada informasi a tau pengetahuan yang diser takan pada pesan tersebut . Contoh unsigned securi ty token in i adalah penggunaan User name/Password . Signature d igunakan untuk memverif ikasi keasl ian dan integri tas pesan. Signature juga dapat digunakan oleh Pengir im untuk menunjukkan kunci yang digunakan untuk menkonfirmasi cla im yang ada dalam securi ty token , sehingga memberikan ident i tas pada pesan tersebut . WSS-Core menspesif ikasikan proteksi pesan dengan menerapkan enkripsi dan digi tal s ignature pada Header dan/atau Body dar i pesan SOAP untuk menjamin integri tas dan kerahas iaan pesan. Integri tas pesan diber ikan dengan menerapkan XML Signature bersamaan dengan securi ty token untuk menjamin bahwa modif ikasi terhadap pesan dapat di teksi . Semnetara i tu , kerahasiaan pesan diber ikan dengan



menerapkan XML Encrypt ion bersamaan dengan securi ty token untuk mempertahankan kerahasiaan bagian pesan SOAP. 5 .1 .3 Security Header Set iap pesan SOAP mempunyai suatu Penerima yang ber t indak sebagai penerima pesan dan merespon pesan. WS-Securi ty vers i or iginal menyebut penerima sebagai Aktor . Sehingga, set iap pesan SOAP pal ing t idak mempunyai satu Aktor , yai tu orang ber t indak berdasarkan pada pesan SOAP tersebut . Suatu pesan dapat mempunyai lebih dar i satu Aktor j ika melalu i sederetan node intermediary , seper t i yang akan di je laskan pada spesif ikasi WS-Routing . Informasi yang berhubungan dengan keamanan pesan SOAP diser takan (attach ) pada bagian Header dari SOAP, tepatnya dalam blok yang diawal i dengan tag . Blok in i menyediakan mekanisme untuk menyertakan informasi yang berkai tan dengan keamanan pada penerima ter tentu, dan dispesif ikasikan oleh atr ibut Actor . Contoh syntax Header pada pesan SOAP menurut vers i WS-Securi ty vers i or is inal di tunjukkan pada gambar dibawah ini .

Gambar 5 .2 - S truktur syntax Pesan SOAP (vers i or is ina l) Untuk set iap target Penerima yang berbeda, informasi yang berkai tan dengan keamanan harus di tul iskan dalam elemen Securi ty Header yang berbeda. Sehingga Securi ty Header dapat muncul beberapa kal i dalam pesan SOAP. Dalam perjalanannya, satu atau lebih Header baru dapat d i tambahkan j ika diper lukan penambahan Target Penerima baru yang belum dispesif ikasikan. Atr ibut Actor dalam set iap Securi ty Header mengident i f ikasikan siapa yang menerima informasi keamanan tersebut . J ika a t r ibut Actor t idak disebutkan, e lemen Securi ty Header dapat dikonsumsi oleh set iap orang, te tapi t idak dapat dihapus sampai mencapai tujuan akhirnya. Elemen Securi ty Header juga menunjukkan tahapan ekripsi dan penandatanganan yang di lakukan oleh Pengir im ket ika membuat pesan SOAP. Securi ty Header di tambahkan pada pesan SOAP secara berurutan terhadap elemen yang suda ada, untuk menjamin bahwa apl ikasi penerima dapat memproses se t iap sub-elemen sesuai dengan urutan keberadaannya pada e lemen Header . Namun demikian, Spesi f ikasi WS-Securi ty ini t idak menyebutkan secara khusus mode pengurutan untuk pengolahan sub-elemen tersebut , sehingga apl ikasi Penerima dapat menggunakan apapun Pol icy yang diper lukan. Dalam spesif ikasi terbaru WSS-Core (WSS: SOAP Message Securi ty) yang di te tapkan OASIS Web Service Securi ty TC (WSS), a t r ibut untuk aktor in i didigant i

...

...

... ...



dengan atr ibut role , dan spesif ikasi Securi ty Header terbaru menjadi sebagai ber ikut :

Gambar 5 .3- S truktur syntax Pesan SOAP (vers i WSS Core) Elemen Securi ty yang dapat dimasukkan dalam Securi ty Header pada pesan SOAP antara la in adalah :

User Name Token Binary Securi ty Token (misalnya untuk X.509 Cert i f icate dan Karberos) XML Token (Securi tyTokenReference) ds:KeyInfo ds:Signature XML Encrypt ion TimeStamp

Contoh penggunaan securi ty token , signature dan encrypt ion sesuai dengan spesif ikasi WSS-Core secara lengkap dapat di l ihat ber ikut in i :

(001) (002) (003) (004) (005) (006) 2001-09-13T08:42:00Z (008) (009) (010)

(011) MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... (012) (013) (014)



"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> (015) (016) MIGfMa0GCSq... (017) (018) (019) (020) d2FpbmdvbGRfE0lm4byV0... (021) (022) (023) (024) (025) (026) (027) (028) (029) (030) (031) (032) (033) (34) (035) (036) LyLsF094hPi4wPU... (037) (038) (039) (040) (041) (042) (043) (044) LyLsF094hPi4wPU... (045) (046) (047) (048) (049) Hp1ZkmFZ/2kQLXDJbchm5gK... (050) (051) (052) wsse:SecurityTokenReference> (053) (054) (055) (056) (057) (058) (059)



(060)

(061)

(062) (063) d2FpbmdvbGRfE0lm4byV0... (064) (065) (066) (067) (068)

5.2 SKENARIO PENGGUNAAN WS-Security Mekanisme WS-Securi ty dapat di terapkan untuk mengatasi berbagai isu keamanan. Berikut ini adalah beberapa contoh skenario untuk mendukung implementas i WS-Securi ty berdasarkan usulan oleh IBM dan Microsoft dalam dokumen WS-Securi ty AppNotes (15 Agustus 2002) , yai tu :

Direct Trust using User Name/Password skenario in i mengilustrasikan proses o tent ikasi menggunakan User Name dan Password dengan t ransport-level securi ty

Direct Trust using Securi ty Token- skenario ini mengi lust rasikan direct t rust menggunakan X.509 cer t i f icate dan Karberos service t icket .

Securi ty Token Acquis i t ion skenario ini mengi lustras ikan otent ikasi menggunakan securi ty token

Firewall Processing - skenario ini mengilustrasikan bagaimana f i rewal l dapat mendukung WS-Securi ty dengan derajat kendal i yang besar .

Issued Securi ty Token - skenario ini mengilust rasikan mekanisme otent ikasi dasar

Direct Trust using User Name/Password

Server dimana Web Service berada menggunakan pasangan publ ic key untuk menjamin keamanan kanal antara server dan cl ient melalui koneksi HTTP dengan menggunakan SSL/TSL. Requester membuka koneksi ke Web Service dengan menggunakan transport- level securi ty (SSL/TSL), d imana Requester mengir imkan pesan permintaan dengan menyertakan securi ty token yang ber is i user name dan password . Sementara Web Service meng-otent ikasi informasi yang terdapat dalam pesan, memproses request dan merespon hasi lnya. Dalam skenario ini in tegri tas dan kerahasiaan pesan di tangani dengan menggunakan mekanisme keamanan berbasis t ransport- layer .



Contoh pesan SOAP yang dikir im dar i Requester ke Web Service pada scenario ini adalah sebagai ber ikut :

(001) (002) (003)

(004) (005) Zoe (006) ILoveDogs (007) (008) (009) (010) (011) (012) DIS (013) (014) (015)

Direct Trust using Securi ty Token

Skenario ini mengilust rasikan penggunaan securi ty token yang secara langsung dipercaya val id ( t rus ted ) oleh Web Service. Dalam hal ini , direct t rust berar t i bahwa securi ty token dikenal dan d iver i f ikasi oleh Web Service. Skenario ini menganggap bahwa Requester dan Web Service te lah menggunakan beberapa mekanisme untuk menetapkan trust relat ionship dalam menggunakan securi ty token . Dengan kata la in , kedua belah pihak memahami dengan baik pol icy untuk privacy masing-masing. Requester mengir im pesan ke Web Service dengan dengan menyertakan securi ty token , dan memberikan proof-o f-possession (publ ic /private key) terhadap securi ty token menggunakan digi tal s ignature . Service melakukan ver if ikasi terhadap public/private key dan mengevaluasi securi ty token, memproses permintaan dan mengembalikan hasi l pemrosesannya. Contoh pesan SOAP yang dikir im dar i Requester ke Web Service pada scenario ini adalah sebagai ber ikut :



(001) (002) (003) (004) http://fabrikam123.com/getQuote (005) http://fabrikam123.com/stocks (006) mailto:[email protected] (007) uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6 (008) (009) (010)

(011) MIIDQTCCAqqgAwIBAgICAZIhvcNAQEFBQAwTjELMAkGA1UEBhMCS... (012) (013) (014) (015) (016) (017) (018) (019) (020) (021) (022) (023) yH8GsCH3FT747UhqqzHqqSTj7CM= (024) (025) (026) (027) TQtb/T9NTGgRzbtDCctfw0SKY7/PHVZtPMFoLtPCixU3Kobis/Q... (028) (029) (030) (031) (032) (033) (034) (035) (036) (037) (038) (039) DIS (040) (041) (042)



Securi ty Token Acquisi t ion

Dalam skenario ini , securi ty token t idak terdapat dalam pesan SOAP, melainkan menggunakan mekanisme securi ty token reference untuk mencari dan mengambil token. Requester mengir im pesan ke service dengan menyebutkan referensi terhadap keberadaan securi ty token , dan menyediakan proof-of-possession dalam bentuk XML Signature . Web Service menggunakan informasi yang ada pada securi ty token reference untuk memperoleh securi ty token dar i securi ty token service dan memvalidasi private/publ ic key (proof) . Web Service menerima ( trusted ) securi ty token , sehingga request d iproses dan dikembalikan hasi lnya ke requester . Contoh pesan SOAP yang dikir im dar i Requester ke Web Service pada scenario ini adalah sebagai ber ikut :

xmlns:S="http://www.w3.org/2001/12/soap-envelope">

(002) (003) (004) http://fabrikam123.com/getQuote (005) http://fabrikam123.com/stocks (006) mailto:[email protected] (007) uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6 (008) (009)

(010) (011) (012) (013) (014) (015) (016) (017) (018) (019) (020) (021)



(022) (023) yH8G3FT747UhqqzHqqSTj7CM= (024) (025) (026) (027) TQtb/+yR56T9NTGgRzbtDCctfw0SKY7/Pq2FoLtPCixU3Kobis/Q... (028) (029) (030) (031) (032) (033) (034) (035) (036) (037) (038) (039) DIS (040) (041) (042)

Firewall Processing

Firewal l melakukan evaluasi terhadap pesan SOAP yang datang, dan hanya mengi j inkan pesan yang berasal dar i requester yang te lah d iotor isasi untuk melewat i Firewal l . Dalam skenario in i , Firewall membuat keputusan dengan mengevaluas i securi ty token yang digunakan untuk menandatangani pesan. Dalam skenario yang la in , Firewal l dapat juga ber t indak sebagai securi ty token yang meminta otor i tas dan hanya mengi j inkan pesan yang memil ik i proof-o f-possess ion (pr ivate/publ ic key) terhadap securi ty token yang diminta o leh Firewal l . Contoh pesan SOAP yang dikir im dar i Requester ke Web Service pada skenar io ini adalah sebagai ber ikut :



(001) (002) (003) (004) http://fabrikam123.com/getQuote (005) http://fabrikam123.com/stocks (006) (007) http://firewall.fabrikam123.com/ (008) (009) mailto:[email protected] (010) uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6 (011) (012)

(013)

(014) MIIDQTCCAqqgAwIBAgICAQQwDQYJ... (015) (016) (017) (018) (019) (020) (021) (022) (023) (024) (025) (026) yH8GsCH3FTqzHqqSTj7CM= (027) (028) (029) (030) f5JJPvwToxNBBzy5R3om/ZtTK63jw... (031) (032) (033) (034) (035) (036) (037) (038) (39)



S:mustUnderstand="1"> (040)

(041) MIIDQTCCAqqgAwIBAgICAQQwDQYJKoZIhvcNAQEF... (042) (043) (044) (045) (046) (047) (048) (049) (050) (051) (052) (053) yH8GsCH3FT7qqSTj7CM= (054) (055) (056) (057) OZ21MKnCQi2Jglw2qIO5e1azezl/j0BP3h2Ut... (058) (059) (060) (061) (062) (063) (064) (065) (066) (067) (068) m:GetLastTradePrice xmlns:m="http://www.fabrikam123.com/"> (069) DIS (070) (071) (072)



Issued Securi ty Token

Skenario ini hampir sama dengan Securi ty Token Acquis i t ion, kecual i bahwa securi ty token dikir im ke Requester dar i Securi ty Token Service , kemudian pesan permintaan dikir im ke Web Service dengan menyertakan securi ty token tersebut menggunakan elemen . Securi ty token dapat berupa X.509 atau Karberos. Sekal i securi ty token diki r im oleh Secuir ty token service, securi ty token tersebut dapat d igunakan beberapa kal i o leh, misalnya untuk Web Service yang berbeda j ika token yang dikir im mengij inkan hal tersebut .



BAB VI

KESIMPULAN Arsitektur dan teknologi Web Service sangat rentan terhadap upaya gangguan keamanan dari pihak-pihak yang t idak dikehendaki (attacker) . Jenis gangguan kemanan yang dihadapi oleh Web Service pada dasarnya sama dengan yang dihadapi oleh sistem berbasis Web lainnya. Tetapi Web Service memperkenalkan sumber sumber kerentanan tambahan yang secara spesifik berasal dari protokol berbasis XML (SOAP dan WSDL) yang digunakan dalam Web Service. Oleh karena i tu standard keamanan yang ada saat ini sepert i SSL/TSL tidak cukup memadai, walaupun masih memegang peranan penting, j ika digunakan untuk mengamankan transaksi berbasis Web Service, karena hanya dapat mengamankan dalam konteks point-to-point . Implementasi Web Service membutuhkan konsep keamanan pada level application layer yang bersifat end-to-end . Dari beberapa spesifikasi stndard keamanan Web Service yang ada, WS-Security menyediakan arst i tektur keamanan yang lebih komprehensif dan independen terhadap teknologi keamanan yang ada. Spesifikasi WS-Security ditujukan untuk mengamankan pesan SOAP pada bagian header maupun body . Konsep WS-Security menekankan pada pemanfaatan teknologi keamanan yang sudah ada, namun dapat mengantisipasi perkembangan teknologi dimasa depan. WS-Securi ty menjamin integritas data dan kerahasiaan (confidentiali ty) dengan mengimplementasikan teknologi XML Signature dan XML Encryption. Disamping i tu, WS-Security menerapkan konsep mengenai secure messaging dengan menggunakan securi ty token untuk mengimplementasikan teknologi kemanan yang ada seperti C.509 certif icate maupun Karberos akan memberikan jaminan pada aspek otenti tas dan otorisasi . Adopsi spesifikasi WS-Security oleh para platform vendor maupun pengembang perangkat lunak (software developer) sangat menentukan prospek penerapan Web Service secara luas. Disisi lain, adopsi spesifikasi WS-Security j ika dikai tkan dengan aspek perfomansi sistem akan menjadi pert imbangan yang dilematis bagi pengguna maupun pengembang perangkat lunak yang akan menggunakan teknologi Web Service.

)OoO(

DAFTAR PUSTAKA [1] Andrew Yang, Implement Web Service Securely , .NET Magazine, Technical

Edi t ion, 2003. Avai lable : http://www.ftponline.com/wss/2003_TE/magazine/features/ayang/

[2] Andy Yang, Web Service Security, eAI Journal, September, 2002. Available :

http://eaijournal.com/PDF/Yang.pdf [3] Caroline Clewlow, SOAP and Security, Whitepaper, Microsoft Corporation, October 2002.

Available : http://www.qinetiq.com [4] David Chappell, WS-Security: New Technologies Help You Make Your Web Service More Secure ,

Microsoft Corporation, 2003. Available : http://msdn.microsoft.com/msdnmag/issues/03/04/WS-Security/ [5] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana: Web Services Description Language

(WSDL) 1.1, 15 March 2001. Available : http://www.w3.org/TR/wsdl. [6] IBM and Microsoft: Security in a Web Services World: A Proposed Architecture and Roadmap,

Whitepaper, Version 1.0, 7 April 2002. Available : http://www-106.ibm.com/developerworks/library/ws-secmap/

[7] IBM and Microsoft: Web Service Security (WS-Security), Specification, Version 1.0, 02 April

2002. Available : http://www-106.ibm.com/developerworks/library/ws-secure/ [8] IBM and Microsoft: WS-Security AppNotes, Whitepaper, Version 1.0, 15 Agustus 2002.

Available : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security-appnote.asp

[9] M. Curphey, D. Endler, W. Hau, S. Taylor at al., A Guide to Building Secure Web Applications: The

Open Web Application Security Project, 11 September 2002 . Available : http://www.owasp.org/guide/ . [10] Maria Tzvetanova, Security for Web Service, Master Thesis, University of Constance , May,

2003. Available : http://www.inf.uni-konstanz.de/~tzvetano/assets/docs/security_for_webservices.pdf [11] M. Champion, Ch. Ferris, E. Newcomer, D. Orchard, Web Services Architecture, W3C Working

Draft , 14 November 2002. Available : http://www.w3.org/TR/ws-arch . [12] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, E. Simon, XML Signature Syntax and Processing,

W3C Recommendation, 12 February 2002 . Available : http://www.w3.org/TR/xmldsig-core/ [13] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, C. Henrik Frystyk Nielsen, SOAP Version

1.2 Part 1: Messaging Framework , W3C Recommendation , 24 June 2003. Available : http://www.w3.org/TR/SOAP.

[14] Mark ONeil l , Archi tect ing Securi ty for Web Service, JAVAPro, Agustus

2003. Avai lable : http://www.ftponline.com/javapro/2003_08/magazine/features/moneill/default_pf.aspx

[15] M. Hondo,Securing Web Services, IBM System Journal, Volume 41, Number 2, 02 April 2002 .

Available : http://www.research.ibm.com/journal/sj/412/hondo.html [16] OASIS Security Services Technical Committee, Assertions and Protocol for the OASIS Security

Assertion Markup Language (SAML), Committee Specification 01, 31 May 2002. Available : http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf

[17] OASIS Security Services Technical Committee, Security Assertion Markup Language, 1 December 2002 .

Available : http://www.oasis-open.org/committees/security/ [18] OASIS Web Services Technical Committee, Web Services Security Core Specification, Working

Draft 17, 27 Agustus 2003. Available : http://www.oasis-open.org/committees/wss/documents/WSS-Core-17-082703-merged.pdf

[19] Scott Seely, Understanding WS-Security, Microsoft Corporation, October 2002. Available : http://www-106.ibm.com/developerworks/library/ws-secmap/

[20] The Stencil Group, Inc., The Evolution of UDDI, UDDI.org, White Paper, 19 July 2002.

Available : http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf. [21] T. Imamura, B. Dillaway, E. Simon, XML Encryption Syntax and Processing, W3C

Recommendation 10 December 2002 . Available : http://www.w3.org/TR/xmlenc-core/ [22] Westbridge Technology,Inc., Technology Managers Guide to XML Web Service Security, 6

Januari 2003. Available : http://www.westbridgetech.com

Documents

keamanan-webservice-wcf