Webservice

This is the html version of the file http://www.cert.or.
id/~budi/courses/ec7010/2003/report-
rusiawan.pdf.
Google automatically generates html versions of documents as we crawl the web.
Page 1
TINJAUAN ASPEK KEAMANAN

SISTEM 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 Elektro
Institut Teknologi Bandung
2003
Page 2
Abstrak
Web Service memberikan paradigma baru dalam mengimplemen-
tasikan 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 jika digunakan untuk mendukung
transaksi bisnis melalui Internet (global). Alasan utama yang menjadi
perhatian adalah pada aspek keamanan dan kerentanan (vulnerability)
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.
Page 3
DAFTAR ISI
Abstrak
…………………………………………………………………. i
Daftar Isi
...................................................................... ii
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
Spesifikasi Keamanan Web Service .......................................... 17
BAB V - STANDARD KEAMANAN WEB SERVICE ......................
19
5.1 Spesifikasi 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
Page 4
Tinjauan Aspek Keamanan Sistem Web Service
Tugas EC-7010 : Keamanan Sistem Lanjut 2003
1
BAB I
PENDAHULUAN
Perkembangan Internet ikut mempengaruhi evolusi perkembangan sistem
terdistribusi (distributed system), dari sistem yang berdasarkan pada platform
proprietary (DCOM, CORBA, RMI) menuju platform yang lebih terbuka (Web).
Momentum perkembangan ini diawali dengan kehadiran XML (eXtensible Markup
Language) untuk mendukung pertukaran data berbasis Web secara lebih fleksibel.
Keberadaan standard XML kemudian ikut mendorong penetapan standard protokol
komunikasi untuk mendukung mekanisme transfer data pada sistem terdistribusi
melalui jaringan Internet yang dikenal sebagai Simple Object Access Protokol
(SOAP) pada tahun 1998. Pada akhirnya kedua teknologi ini (XML dan SOAP)
kemudian mendasari perkembangan arsitektur teknologi yang memungkinkan untuk
menerapkan konsep sistem terdistribusi pada jaringan Internet berbasis Web, yang
kemudian dikenal sebagai Web Service.
Standard XML dan SOAP dikembangkan oleh World Wide Web Consortium
(W3C). Selanjutnya, W3C juga terlibat dalam pengembangan standard protokol dan
arsitektur untuk Web Service, seperti WSDL (Web Service Description Language),
termasuk standard teknologi kemanan untuk Web Service seperti XML Encryption,
XML Signature, dls. Disamping W3C, beberapa organisasi lain saat ini juga terlibat
dalam pengembangan standard untuk Web Service, seperti Organization for
Advancement of Structured Information Standard
(OASIS), Web Service
Interoperability Organization (WS-I), dan Liberty Alliance Technology Group yang
disponsori oleh Sun Microsystem.
Web Service memiliki keunggulan dibanding teknologi dengan sistem
terdistribusi yang sudah ada seperti CORBA, DCOM dan RMI karena karakteristik
Web Service yang bersifat terbuka, non-propriertary, loosely coupled, dan modular.
Web Service dapat diimplementasikan baik untuk lingkungan internal (Intranet)
maupun untuk lingkungan publik (Internet). Dalam lingkungan internal, Web Service
memberikan kemudahan dan solusi baru untuk mengintegrasikan berbagai platform
aplikasi yang ada dalam organisasi/perusahaan (Enterprises Application
Integration/EAI). Dalam lingkungan publik, Web Service akan memperbaruhui
konsep transaksi berbasis Internet seperti e-business dengan cara mengintegrasikan
proses bisnis dengan partner bisnis secara lebih mudah, sederhana dan murah. Dan
secara umum, Web Service akan mengubah paradigma para pengguna maupun
pengembang perangkat lunak , dari API (application program interface)-based
menjadi message-based.
1.1 PERMASALAHAN
Walaupun Web Service menjanjikan solusi untuk mengatasi kelemahan
teknologi berbasis Web pada umumnya, namun demikian masih banyak yang merasa
ragu untuk segera menerapkan Web Service, khususnya pada lingkungan Internet
(publik), misalnya untuk mendukung transaksi e-business. Keraguan ini disebabkan
oleh faktor jaminan keamanan dari teknologi Web Service. Survey menunjukkan
Page 5
2
bahwa faktor keamanan merupakan masalah utama yang menjadi perhatian dalam
mengimplementasikan Web Service.
Teknologi keamanan yang biasa digunakan untuk mengatasi aspek keamanan
pada sistem berbasis Web pada umumnya, seperti Secure socket Layer (SSL)/
Transport Secure Layer (TSL), tidak cukup memadai jika diterapkan pada sistem
berbasis Web Service. Hal ini dikarenakan SSL/TLS menyediakan solusi kemanan
dengan konteks point-to-point pada level transport layer. Sementara karakteristik
transaksi Web Service, membutuhkan pengamanan dalam konteks end-to-end pada
level application layer. Teknologi Firewall yang menyediakan pengamanan pada
level Network Layer juga tidak cukup memadai, karena karakteristik transaksi Web
Service yang menggunakan standard internet (HTTP, SMTP, FTP) akan dilewatkan
oleh Firewall karena dianggap Sebagai trafik Internet pada umumnya (firewall
friendly).
Walaupun teknologi keamanan yang ada saat ini masih memegang peranan
penting, namun demikian masih diperlukan suatu mekanisme keamanan pada level
appplication layer yang dapat diterima luas oleh berbagai pihak yang terlibat dalam
implementasi Web Service, dan mendukung aspek interoperabilitas dalam
mengimplementasikan Web Service. Keberadaan standard kemananan Web Service
tersebut akan sangat mempengaruhi prospek penerapan Web Service secara luas.
1.2
TUJUAN PENULISAN
Tujuan penulisan makalah ini adalah untuk memberikan tinjauan umum
mengenai berbagai aspek yang menyangkut keamanan dalam mengimplementasikan
sistem Web Service, antara lain meliputi :
▪ Konsep dasar teknologi Web Service yang relatif masih baru sehingga perlu
ada penjelasan khusus
▪ Aspek kerentanan dan keamanan dari Web Service yang perlu diperhatikan
dalam mengimplementasikan Web Service
▪ Model Arsitektur Keamanan Web Service yang secara konsepsual memberi
landasan dalam mengembangkan spesifikasi keamanan Web Service
▪ Standard Kemanan untuk Web Service yang ada dan sedang dikembangkan saat
ini, khususnya terhadap spesifikasi WS-Security yang akan menjadi
spesifikasi inti untuk digunakan dalam mengamankan sistem Web Service.
Page 6
3
BAB II
WEB SERVICE
Ada berbagai versi definisi mengenai Web Service, yang pada intinya
menggambarkan karakteristik dari Web Service, yaitu antara lain sebagai berikut :
▪ Merupakan application logic yang dapat diakses dan dipublikasikan
menggunakan standard Internet (TCP/IP, HTTP, Web).
▪ Dideskripsikan dalam format XML.
▪ Didentifikasikan dengan Universal Resources Identifier (URI)
▪ Bersifat Loosely coupled, self-contained, modular dan terbuka (non-
proprietary)
▪ Digunakan untuk mendukung interoperabilitas interaksi machine-to-machine
melalui jaringan Internet/Intranet.
Web Service dapat diimplementasikan pada lingkungan internal (Intranet)
untuk kebutuhan integrasi antar sistem aplikasi (EAI=Enterprise Application
Integration) ataupun pada lingkungan eksternal (Internet) untuk mendukung aplikasi
business-to-business (e-business).
2.1 ARSITEKTUR WEB SERVICE
Konsep arsitektur yang mendasari teknologi Web service adalah Service
Oriented Architecure (SOA). Dalam aritektur ini, suatu aplikasi dimodelkan sebagai
komposisi dari sekumpulan service yang disediakan oleh suatu komponen. Lokasi
keberadaan komponen tersebut dapat ditemukan oleh client secara dinamis, dalam
arti tidak dinyatakan secara statis tetapi menggunakan mekanisme discovery untuk
mencari keberadaan komponen tersebut. Demikian pula, client dapat meminta
(invoke) service tersebut secara dinamis pula. Dalam arsitektur ini, SOA
mendefinisikan 3 peran berbeda yang menunjukkan peran dari masing-masing
komponen dalam sistem, yaitu :
▪ Service provider, yaitu suatu entitas yang menyediakan interface terhadap
sistem yang menjalankan suatu sekumpulan tugas tertentu.
Service provider dapat merepresentasikan statu entitas bisnis
ataupun suatu komponen software yang reusable.
▪ Service requestor , yaitu suatu entitas yang meminta/memperoleh (dan
menemukan) software service dalam rangka meyelesai kan
suatu tugas tertentu atau menyediakan solusi bisnis tertentu.
▪ Service registry , yaitu entitas yang bertindak sebagai penyimpan (repository)
suatu software service yang dipublikasikan oleh Service
provider.
Peran dan interaksi antar komponen tersebut ditunjukkan pada gambar dibawah
ini :
Page 7
4
Gambar 2.1- Konsep Service Oriented Architecture
Dalam arsitektur ini, Service dapat didefinisikan sebagai komponen (software
component) yang memiliki karakteristik :
▪ Dapat dideskripsikan dalam suatu bahasa formal
▪ Dapat dipublikasikan pada suatu registry of service
▪ Dapat ditemukan (discover) menggunakan mekanisme standard
▪ Dapat diminta/diperoleh (invoke) melalui jaringan
▪ Dapat dibangun bersama service lain
W3C mengilustrasikan model SOA tersebut sebagai deskripsi pesan yang
dipertukarkan, seperti ditunjukkan pada gamber berikut ini.
Gambar 2.2- Diagram generik Model Service Oriented Architecture
.
Model Arsitektur Web Service menggunakan konsep SOA tersebut dengan
sedikit perbedaan, yaitu :
▪ Web Service menggunakan Standard terbuka, yaitu : XML (eXtensible Markup
Language) sebagai bahasa untuk mendeskripsikan data, SOAP (Simple Object
Access Protocol) sebagai protokol komunikasi antar komponen , WSDL (Web
Service Description Language) untuk mendesktipsikan service, UDDI
(Universal Description, Discovery and Integration) untuk service discovery,
dan HTTP sebagai transport layer.
Page 8
5
▪ Standard Web Service merupakan message-based, bukan API-based. Dalam
hal ini, komunikasi antara Web Service, Service Requester dan Service
Registry menggunakan pesan SOAP berbasis XML.
W3C mengembangkan draft arsitektur Web Service yang terdiri dari beberapa
teknologi yang saling berhubungan dan berlapis seperti digambarkan sebagai
berikut :
Gambar 2.3- Arsitektur Web Service
2.2 STANDARD TEKNOLOGI WEB SERVICE
Seperti yang ditunjukkan pada Gambar 1.3 tersebut diatas, Web service
tersusun dari beberapa komponen standard berbasis XML, yaitu : SOAP, WSDL, dan
UDDI.
Simple Object Access Protocol (SOAP)
SOAP merupakan suatu protokol berbasis XML yang digunakan untuk kebutuhan
pertukaran informasi dalam suatu sistem terdistribusi dan terdesentralisasi, seperti
halnya IIOP (pada CORBA), ORCP (pada DCOM) dan JRMP (pada RMI). Berbeda
dengan RMI, CORBA dan DCOM, SOAP merupakan protokol yang bersifat
independent terhadap platform, model pemrograman, dan transport protocol yang
digunakan dalam proses pertukaran pesan SOAP. Pesan SOAP dapat dikirimkan
melalui HTTP, SMTP maupun FTP.
Pesan SOAP berbentuk sekumpulan XML Schema yang mendefinisikan format
untuk mentransmisikan pesan XML melalui jaringan, termasuk tipe data dan cara
menstrukturkan pesan secara tepat sehingga dapat mudah dipahami oleh server atau
end-point lainnya.
Page 9
6
Pesan SOAP terdiri dari 3 bagian, yaitu :
▪ Envelope , suatu kerangka yang mendefinisikan apa yang ada dalam pesan
dan bagaimana pesan harus diproses serta menunjukkan resipien dari
message tersebut.
▪ Header , berisi informasi yang berhubungan dengan keamanan dan routing.
Keberadaan Header dalam SOAP bersifat optional.
▪ Body , berisi data yang berhubungan dengan aplikasi tertentu yang sedang
dipertukarkan. Data di-‘mark-up’ sebagai XML dan dimasukkan dalam
format yang spesifik yang didefinisikan dalam XML Schema.
Standard SOAP yang dikembangkan oleh W3C versi terakhir adalah SOAP versi
1.2 yang ditetapkan pada 24 Juni 2003.
Web Service Description Language (WSDL)
WSDL merupakan bahasa standard yang menyediakan mekanisme untuk
mendeskripsikan Service yang disediakan oleh sistem (Web service), lokasi
keberadaan service tersebut dan bagaimana cara memperolehnya, secara terstruktur
dalam format XML. WSDL dapat dianalogikan sebagai IDL (interface definition
language) dalam CORBA dan COM. Service dedeskripsi kan sebagai koleksi dari
entry-point atau port komunikasi. WSDL mendeskripsikan service dengan
menggunakan elemen sebagai berikut :
• Type – tipe data yang digunakan sebagai argumen dan return type
• Message – merepresentasikan definisi data yang ditransmisikan
• Port type – sekumpulan operasi yang didukung oleh satu atu lebih endpoint
• Binding – mendefinisikan protokol dan format pertakaran data untuk operasi
yang didefinisikan oleh Port type
• Port – menspesifikasikan end-point yang digunakan untuk binding
• Service – koleksi endpoint yang berkaitan yang disediakan oleh Web service
• Operation – mendefinisikan kemampuan yang didukung oleh servis tertentu
Universal Description, Discovery & Integration (UDDI)
UDDI merupakan sekumpulan spesifikasi yang menunjukkan registry informasi
mengenai Webservice. UDDI menyediakan mekanisme untuk mempublikasikan
informasi mengenai bisnis dan service pada satu lokasi (repository) yang dikelola
secara terpusat dan melakukan query mengenai informasi tersebut secara dinamis dan
programatis. Direktory pada UDDI bertindak seperti ‘Yellow Pages’ dimana service
dikategorikan sesuai tujuan utamanya. Direktory UDDI terdiri dari 3 bagian, yaitu :
• White pages – menyediakan informasi rinci mengenai organisasi yang
menawarkan service
• Yellow pages – mencakup pengakatagorian jenis industri berdasarkan standard
taxonomi industri
• Green pages – mendeskripsikan interface dan kebutuhan untuk memperoleh
service , seperti return type.
UDDI merupakan file XML Schema yang mendefinisikan struktur data
mengenai karakteristik bisnis dan service. Deskrisi service didefinisikan
menggunakan dokumen Type Model (tModel). Secara umum UDDI berisi informasi
mengenai siapa yang menyediakan service (businessEntity), Service apa yang
disediakan (businessService), dimana lokasi service tersedia (bindingTemplate),
referensi mengenai informasi bagaimana service tersebut diperoleh (tModel).
Page 10
7
BAB III
ASPEK KERENTANAN DAN KEAMANAN
WEB SERVICE
Pada dasarnya sistem Web Service memiliki kerentanan (vulnerability) dasar
yang sama dengan sistem berbasis Web lainnya yang menggunakan protokol HTTP.
Namun demikian, karena Web Service memiliki arsitektur sistem yang agak berbeda
dengan sistem berbasis Web lainnya, maka Web Service memiliki kerentanan
tambahan yang spesifik. Karentanan ini bersumber pada arsitektur Web Service dan
protokol yang digunakan, yaitu dalam hal ini adalah : SOAP (Simple Object Access
Protocol) yang berbasis XML (eXtended Mark-up Language).
3.1 SUMBER KERENTANAN WEB SERVICE
Disamping memiliki memiliki kerentanan yang sama seperti aplikasi berbasis
Web lainnya (HTTP), Web Service memiliki kerentanan tambahan yang disebabkan
oleh karakteristik teknologi yang mendasari Web Service, yaitu XML dan SOAP.
Oleh karena itu standard keamanan yang biasa digunakan pada aplikasi berbasis Web
tidak cukup memadai jika diterapkan pada Web Service.
Karakteristik spesifik yang menjadi sumber kerentanan pada Web Service
terletak pada 2 hal berikut ini, yaitu :
▪ Protokol yang menjadi dasar teknologi Web Service, yaitu SOAP yang
berbasis XML.
▪ Arsitektur Web Service yang memberi landasan dalam hal mekanisme
transaksi dan implementasi Web Service.
Dalam subbab berikut ini pertama-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 Vulnerability)
XML (eXtensible Mark-up Language) digunakan sebagai teknologi dasar dari
Web Service berdasarkan pertimbangan bahwa XML merupakan standard yang
terbuka dan telah diterima secara luas untuk mendukung transaksi berbasis Internet.
Dalam Arsitektur Web Service, XML diimplementasikan untuk menspesifikasikan
elemen utama Web Service, yaitu :
▪ Communication Protocol : SOAP (Simple Object Access Protocol)
▪ Service Description : WSDL
▪ Service Publication & Discovery : UDDI.
XML merupakan bahasa generik untuk pertukaran data melalui Internet dan
menjadi standard platform komunikasi dalam sistem yang heterogen. Tidak seperti
HTML, XML memisahkan antara bagian Data (content) dan bagaimana data
ditampilkan (presentation) secara terstruktur. Oleh karena itu, data pada XML
Page 11
8
membuka kemungkinan untuk dapat dimanipulasi oleh siapapun yang dapat
membacanya. XML juga mudah diterjemahkan oleh berbagai bahasa pemrograman.
Karena sifat yang berbasis teks, mudah dibaca oleh manusia (human-readeble), maka
dokumen XML mudah untuk di-debug dan dilewatkan melalui Firewall. Suatu
aplikasi yang berbasis XML dapat mendefinisikan markup tag untuk
merepresentasikan elemen data yang berbeda dalam suatu file teks sedemikian
hingga data dapat dibaca dan diproses oleh apllikasi yang menggunakan XML.
Dengan menggunakan XML, suatu entitas bisnis dapat mendefinisikan suatu policy
dan mengekspresikannya dalam dokumen XML.
Gambar 3.1- Contoh WSDL berbasis XML
Dengan karakteristik yang berbasis teks dan bersifat terbuka tersebut, maka
kelemahan pada XML ini juga dapat menjadi sumber kerentanan pada aplikasi
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 telah menetapkan standard untuk menangani
kerentanan XML, yaitu antara lain : XML Signature, XML Encryption, dan SAML.
Pembahasan selengkapnya mengenai standard SAML ini akan diberikan pada Bab III,
sementara XMLSignature dan XML Encryption sudah dibahas pada laporan tugas
akhir yang sudah ada sebelumnya.
Page 12
9
3.1.2 Kerentanan Pada SOAP
SOAP merupakan standard protokol komunikasi untuk pertukaran informasi
dalam sistem Web Service. Pada umumnya pesan SOAP dikirim melalui protokol
HTTP. Namum demikian pada dasarnya SOAP merupakan protokol yang independen
terhadap layer transport. Dengan kata lain, pesan SOAP juga dapat dikirim melalui
SMTP, atau FTP. Dalam satu transaksi Web Service, suatu pesan SOAP dapat
berjalan melalui layer transport yang berbeda-beda, misalnya, pada tahap pertama
menggunakan HTTP, kemudian diteruskan melalui SMTP, dan seterusnya.
Pada aplikasi berbasis Web, bisanya digunakan standard pengamanan Secure
Socket Layer/Transport Secure Layer (SSL/TSL) untuk mengamankan transaksi
melalui HTTP. SSL memberikan jaminan confidentiality melalui mekanisme enkripsi
dan jaminan otentikasi menggunakan setifikat digital X.509 untuk sesi HTTP yang
bersifat tunggal dan point-to-point. Namun demikian, SSL tidak dapat menyediakan
mekanisme audit trail yang dapat menjamin bahwa sesi tersebut ada atau pernah
terjadi.
Gambar 3.2- Model kemanan dengan konteks point-to-point
Oleh karena itu, solusi terhadap kelemahan dari SSL ini adalah dengan cara
menerapkan mekanisme pengamanan pada pesan SOAP itu sendiri, bukan hanya pada
layer transport dimana pesan SOAP dikirim. Solusi ini menjamin bahwa jika SOAP
dikirim melalui jalur transport yang tidak aman, atau jika pesan SOAP harus dikirim
melalui beberapa layer transport yang berbeda-beda dan dalam lingkungan yang tidak
aman, pesan SOAP tersebut dapat tetap dijamin aman. Misalnya, jika digunakan
analogi antara SOAP dan Email. Jika Email dikirim melalui Internet, maka tidaklah
cukup jika hanya meng-enkrip link antar Mail server, untuk itu pesan Email itu
sendiri juga perlu di-enkrip. Demikian juga halnya dengan pesan SOAP. OASIS
telah mengembangkan standard untuk mengamankan pesan SOAP ini dengan nama
WS-Security yang akan dibahas pada Bab III.
Pada sisi lain, dalam Web Service, pesan SOAP di-generate oleh aplikasi,
bukan oleh manusia/orang. Akan tetapi keputusan untuk pengamanannya tetap
didasarkan pada identitas orang yang melakukan transaksi. Misalnya dalam situasi
dimana Web Service digunakan pada kasus pengadaan barang, dimana seorang buyer
masuk ke suatu Portal Pengadaan Barang dengan mengotentikasi dirinya
menggunakan password untuk membuat Purchase Order request. Pesan SOAP
kemudian dikirim ke beberapa Supplier atas nama Buyer tersebut. Supplier
menggunakan mekanisme pengamanan layer transport untuk meng-otentikasi
pengirim pesan SOAP tersebut, dalam hal ini Portal Pengadaan Barang. Jika Supplier
ingin mengetahui siapa identitas Buyer yang mengirim Purchase Order request
tesebut, apa yang harus dilakukan ? Mekanisme pengamanan layer transport seperti
SSL tidak dapat melakukan kebutuhan demikian. Oleh karena itu konteks keamanan
harus dapat dapat menjamin mekanisme pengamanan end-to-end, dimulai dari end-
Security
Context
Service
Service Provider
Intermediary
Security
Context
Page 13
10
user yang melakukan otentikasi menggunakan password (dalam contoh tersebut
adalah Buyer) sampai dengan Web Service yang bekerja atas nama end-user dengan
menggunakan pesan SOAP.
Gambar 3.3- Model kemanan dengan konteks end-to-end
Dalam hal ini, mekanisme keamanan diterapkan dengan menyisipkan
informasi mengenai identitas user (security information) didalam pesan SOAP.
Informasi tersebut mencakup antara lain : status otentikasi dari end-user (dalam
kasus ini adalah Buyer), aktivitas yang diperbolehkan (otorisasi), dan atribut lain
mengenai user tersebut yang berguna untuk menetapkan access control. OASIS
telah menetapkan standard untuk maksud tersebut dengan nama SAML (Security
Assertion Markup Language) yang menspesifikasikan bagaimana informasi mengenai
identitas user tersebut didefinisikan dalam dokumen XML sebagai pernyataan
(assertion) mengenai user. Sementara itu WS-Security mendefinisikan bagaimana
pernyataan tersebut ditempatkan dalam pesan SOAP. Pembahasan mengenai standard
ini akan dibahas pada Bab III.
3.2 ASPEK PENGAMANAN WEB SERVICE
Secara umum ada 5 aspek keamanan dasar yang perlu diperhatikan dalam
mengimplementasikan sistem berbasis Web pada umumnya termasuk dalam hal ini
adalah aplikasi Web Service, yaitu : Authentication, Authorization, Confidentiality,
Data Integrity dan Non-Repudiation. Disamping itu layanan aplikasi berbasis Web
harus dapat memberikan konteks pengamanan secara end-to-end, dimana setiap
transaksi harus dapat dijamin keamanannya mulai dari asal transaksi sampai dengan
penyelesaian akhir transaksi sehingga dapat mempertahankan keamanan yang
konsisten di semua tahapan pengolahan transaksi.
Otentikasi
Otentikasi (Authentication) merupakan proses untuk mengidentifikasi Pengirim
mupun penerima. Seperti halnya aplikasi berbasis Web lainnya, Service requester
perlu di-otentikasi oleh service provider sebelum informasi dikirim. Sebaliknya,
Service requester juga perlu meng-otentikasi Service provider. Otentikasi sangat
penting dan crucial diterapkan untuk melakukan transaksi di Internet. Saat ini telah
tersedia standard yang biasa digunakan untuk menerapkan mekanisme Otentikasi
pada aplikasi berbasis Web pada umumnya, yaitu antara lain PKI, X.509 Certificate,
Karberos, LDAP, dan Active Directory. Dalam kaitannya dengan Web Service,
dokumen WSDL dapat dirusak melaluji serangan spoofing sedemikian hingga Service
requester berkomunikasi bukan dengan Service privider sesungguhnya, melainkan
Security
Context
Service
Service Provider
Intermediary
Page 14
11
dengan Spoofed Web Service. Oleh karena itu, dokumen WSDL perlu di-otentikasi
untuk menjamin integritas data.
Gambar 3.4- Mekanisme Spoofing terhadap WSDL
Otorisasi
Otorisasi (authorization) menjamin bahwa requester yang telah berhasil melakukan
otentikasi dapt meng-akses sumber daya yang ada sesuai dengan karakteristik akses
(access control) yang disediakan. Aplikasi berbasis Web perlu melindungi data
front-end maupun back-end dan sumber daya sistem lainnya dengan menerapkan
mekanisme kontrol akses, sebagai contoh : apa yang dapat dilakukan oleh
user/aplikasi, sumber daya apa yang dapat diakses, dan operasi apa yang dapat
dilakukan terhadap data tersebut.
Confidenciality
Confidentiality menjamin kerahasiaan (privacy) terhadap data/informasi yang
dipertukarkan yaitu dengan melindungi data/informasi agar tidak mudah dibaca oleh
entitas (orang atau aplikasi) yang tidak berhak. Standard yang biasa digunakan
untuk menjaga kerahasiaan data yang dikirim adalah menggunakan teknologi
Enkripsi, misalnya dengan metode Digital Signature. Service requester
menandatangani dokumen yang dikirimkan dengan suatu private key, dan
mengirimkannya bersamaan dengan body of message. Service provider kemudian
dapat memverifikasi tandatangan tersebut dengan sender’s private key untuk melihat
apakah ada bagian dari dokumen yang telah berubah. Dengan cara ini, sistem dapat
menjamin integritas data ketika melakukan komunikasi satu sama lain.
Integritas Data
Integritas data menghendaki bahwa komunikasi antara client dan server dilindungi
dari adanya kemungkinan untuk merubah data oleh user/aplikasi yang tidak memiliki
hak untuk melakukan perubahan data. Dengan kata lain, Integritas Data menjamin
bahwa data tidak berubah selama proses pengiriman data dari sumber ke tujuan.
Standard yang biasa digunakan untuk mengamankan jalur komunuikasi berbasis
Internet adalah Secure Socket Layer/Transport Layer Security (SSL/TSL) dengan
menggunakan protokol HTTPS. Seperti suda dijelaskan tersebut diatas, SSL/TSL
memiliki konteks keamanan yang bersifat point-to-point antara Service requestor dan
Service provider. Akan tetapi dalam banyak hal, service provider bukan tujuan final
dari pesan yang dikirimkan. Service provider dapat bertindak sebagai Service
Page 15
12
requestor yang mengirimkan pesan ke berbagai Service provider lainnya, seperti
digambarkan sebagai berikut.
Gambar 3.5- Model Transaksi dalam Web Service
Untuk mengamankan mekanisme transaksi seperti tersebut diatas, dibutuhkan
mekanisme keamanan dengan konteks end-to-end security, yaitu dengan
menggunakan standard XML Encryption dengan cara meng-enkrip sebagian dari
format pesan, dimana bagian payload dari pesan di-enkrip, sedang bagian Header
digunakan untuk kebutuhan routing.
Non-Repudiation.
Non-repudiation menjamin bahwa masing-masing pihak yang terlibat dalam transaksi
(client & service provider) tidak dapat menyangkal terjadinya transaksi yang telah
dilakukan. Mekanisme ini dapat dilakukan dengan menggunakan teknologi digital
signature dan timestamping. Dengan teknologi digital signature, Sevice provider
tidak hanya memberikan bukti bahwa telah terjadi transaksi, tetapi juga merekam
tranksaksi pesan kedalam audit log yang telah ditandatangani pula. Sekali audit log
telah ditandatangani, ia tidak dapat dimodifikasi (oleh Hacker) tanpa merubah
tandatangan secara signifikan.
3.3 SERANGAN KEAMANAN PADA WEB SERVICE
Salah satu kunci kesederhanaan Web Service adalah bahwa Web Service
diimpelementasikan pada port 80 dan 443, sama seperti standard aplikasi berbasis
Web lainnya. Keuntungannya adalah dapat menyerdehanakan komunikasi antara
beberapa entitas, tetapi disisi lain memiliki kelemahan dengan membuka peluang
munculnya gangguan keamananan yang kurang dimengerti sebelumnya. Untuk
mengatasinya, biasanya digunakan Firewall yang dapat melakukan tugas seperti port
monitoring dan mengenali adanya serangan yang bersifat brute force, akan tetapi
Firewall tidak dapat melakukan tugas untuk melihat isi pesan sebagai upaya untuk
mendeteksi dan mencegah adanya gangguan keamanan yang yang lebih kompleks.
Pada sisi lain, Firewall tidak dapat memberikan proteksi terhadap serangan yang
berasal dari dalam (internal) perusahaan itu sendiri, seperti yang ditunjukkan pada
gambar berikut ini.
Page 16
13
Gambar 3.6 – Contoh implementasi Keamanan Web Service
dengan meggunakan Firewall
Firewall dapat mengenali pesan SOAP, tetapi menganggapnya hanya sebagai
trafik normal biasa seperti trafik HTTP pada umumnya. Walaupun demikian Firewall
juga dapat diatur (configure) untuk menolak atau mengijinkan trafik SOAP. SOAP
interface merupakan perangkat lunak yang memiliki format Application Program
Interface (API) dan dapat menjalankan berbagai macam fungsi. Misalnya, suatu
aplikasi Web Service dapat terdiri dari ratusan atau ribuan operasi yang dapat
dilakukan, semuanya melalui port 80. Semetara itu dokumen WSDL dan isi UDDI
menyediakan informasi rinci yang memberi peluang untuk Hacker untuk melihat
isinya karena karakteristik XML yang bersifat (self-describing) dan secara jelas
menunjukkan elemen data. Beberapa jenis serangan yang mungkin terjadi terhadap
aplikasi berbasis Web juga bisa terjadi pada aplikasi Web Service, yaitu antara lain
adalah Denial of Service (DOS), Buffer Overflow, Reply Attack, dan Dictionary
Attack.
Gambar 3.7- Jenis gangguan kemanan pada Web Service
Denial Of Service
Contoh serangan yang bersifat denial of service (DOS) ini misalnya pada kasus
dimana suatu applikasi Web Service hanya mampu menerima transaksi persetujuan
pinjaman uang sebanyak 5 permintaan sehari, tetapi suatu serangan DOS dapat
terjadi jika ada 10 permintaan penjaman per jam yang dikirim untuk diproses oleh
sistem. Serangan DOS biasanya akan menyebabkan kelumpuhan sistem karena
kekurangan sumber daya untuk melayani request yang masuk akibat DOS, yang dapat
berakibat berhentinya operasi sistem.
Page 17
14
Buffer Overflow
Serangan buffer overflow pada Web Service terjadi jika ada parameter data yang
dikirim lebih panjang dari pada yang bisa ditangani oleh sistem yang menyebabkan
sistem mengalami crash, atau sistem menjalankan kode yang tidak dikehendaki
(undesired code) yang dikirim oleh penyerang. Metode untuk melakukan ini
biasanya dilakukan dengan cara mengirimkan password dengan jumlah karakter lebih
panjang dari yang diharapkan. Serangan yang sama dengan buffer overflow adalah
dikenal sebagai format string attack, yang berupa pengiriman string atau karakter
yang tidak memiliki fungsi seperti tanda petik, tanda kurung, atau wildcard.
Reply Attack
Reply attck dilakukan dengan menyalin pesan yang valid kemudian mengirimkan
ke Web Service server secara berulang-ulang, seperti halnya DOS. Untuk menangani
serangan ini dapat menggunakan metode yang sama dalam menghadapi DOS. Dalam
beberapa kasus, Reply attack lebih mudah diteksi oleh Web Service karena payload
pesan dapat dengan mudah dibaca. Dengan bantuan tool yang tepat, pola serangan
Reply attack dapat diteksi secara mudah walaupun jira serangan dikirimkan melalui
berbagai medium seperti HTTP, HTTPS, SMTP, atau melalui berbagai interface yang
berbeda.
Dictionary Attack
Dictionary attack terjadi jika seorang hacker menyerang dengan cara mencoba
memasukkan user ID dan Password untuk masuk ke sistem atau berbagai sistem
secara manual atau otomatis (programmatically). Oleh karena itu seorang
Administrator harus dapat meyakinkan bahwa password tidak mudah ditebak dan
selalu diperbaruhui/dirubah secara periodik.
Page 18
15
BAB IV
ARSITEKTUR KEAMANAN WEB SERVICE
Model arsitektur keamanan Web Service menekankan pentingnya
memanfaatkan proses dan teknologi keamanan yang ada saat ini dengan
mengantisipasi kebutuhan keamanan aplikasi untuk masa mendatang. Model ini
menghendaki adanya perhatian terhadap beberapa isu, yaitu : menyatukan berbagai
konsep mengenai keamanan, solusi teknologi (misalnya secure messaging), proses
bisnis (dalam terminologi policy, risk, trust), serta koordinasi antara berbagai pihak
yang terlibat, antara lain : vendor, application developer, network/infratructure
provider, dan customer. Model arsitektur yang dibahas dalam bab ini berdasarkan
usulan dari Microsoft dan IBM dalam “Security in a Web Service World : A Proposed
Architecture and Roadmap”, April 7, 2002, Versi 1.0.
Penyatuan lingkup teknologi keamanan yang ada saat ini dimaksudkan untuk
memisahkan antara kebutuhan keamanan suatu aplikasi dengan mekanisme teknologi
yang digunakan. Tujuannya adalah untuk memudahkan customer dalam membangun
suatu solusi yang saling dapat dioperasikan (interoperable) dalam suatu lingkungan
yang heterogen. Proses integrasi dilakukan dengan membuat abstraksi terhadap suatu
model keamanan tertentu yang memungkinkan suatu organisasi menggunakan
investasi teknologi keamanan yang ada saat ini untuk berkomunikasi dengan
organisasi/perusahaan lain yang menggunakan teknologi yang berbeda.
Pada sisi lain, setiap Web Service mempunyai kebutuhan aspek kemananan
yang unik didasarkan pada kebutuhan bisnis dan lingkungan operasional yang khusus.
Misalnya, untuk kebutuhan internal, maka kesederhanaan dan kemudahan operasional
merupakan tuntutan utama, sementara untuk kebuthan eksternal (Internet) dibutuhkan
kemampuan untuk bertahan terhadap, misalnya, serangan DOS. Untuk mendukung
kebutuhan demikian maka suatu model keamanan Web Service menghendaki adanya
fleksibilitas dalam menggunakan mekanisme keamanan konvensional, tetapi disisi
lain dapat memberikan solusi bagi berbagai macam kebutuhan keamanan sistem
melalui penerapan kebijakan keamanan (security policy) dan perubahan konfigurasi
sistem. Dengan kata lain, model arsitektur kemanan Web Service merupakan
sekumpulan abstraksi keamanan yang menyatukan teknologi yang berbeda-beda yang
telah ada sebelumnya. Model arsitektur demikian dapat memenuhui kebutuhan
customer yang spesifik tetapi pada saat yang sama memungkinkan teknologi untuk
terus berkembang dan dapat diimplementasikan secara bertahap. Sebagai contoh,
suatu Web Service dapat menerapakan model secure messaging (melalui enkripsi
terhadap pesan) ketika mengirim pesan melalui lintasan yang aman dengan
menggunakan mekanisme keamanan berbasis transport layer (SSL/TSL) yang sudah
ada. Sehingga pesan dapat memiliki aspek integritas (atau confidentiality) yang ada
diluar transport layer.
4.1 MODEL ARSITEKTUR KEAMANAN WEB SERVICE
Web Service dapat diakses dengan mengirimkan pesan SOAP ke service end-
point yang diidentifikasikan dengan URI (Unified Reaources Identifier), untuk
meminta aktivitas tertentu pada Web Service, dan kemudian menerima respon pesan
SOAP (termasuk adanya indikasi adanya kesalahan, jika ada). Dalam konteks ini,
tujuan pengamanan Web Service dibagi dalam beberap sub-goal yang menyediakan
fasilitas untuk mengamankan integritas dan confidentiality pesan dan menjamin
Page 19
16
service hanya akan melakukan perkerjaannya sesuai dengan isi pesan yang
merupakan ekspresi dari Claim yang dibutuhkan oleh suatu Policy. Fungsi
pengamanan terhadap integritas dan confidentialitity pesan dapat diterapkan
menggunakan teknologi SSL/TSL maupun IPSec. Namun demikian SSL/TSL maupun
IPSec hanya menyediakan konteks keamanan yang bersifat point-to-point.
Model arsitektur Web Service yang komprehensif membutuhkan mekanisme
keamanan dengan konteks end-to-end. Model ini menghendaki adanya pengamanan
pada layer transport maupun aplikasi.
IBM dan Microsoft mengusulkan suatu model arsitektur keamanan Web
Service untuk memenuhi kebutuhan tersebut diatas dengan suatu karakteristik
sebagai berikut :
▪ Web Service menghendaki bahwa setiap pesan yang masuk dapat menunjukkan
dirinya sebagai sekumpulan claim (misalnya: nama, key, permission,
kapabilitas, dls). Jika suatu pesan datang tanpa memiliki claim yang
dibutuhkan, maka Web Service dapat menolak atau menerima pesan tersebut.
Sekumpulan claim dan informasi yang berkaitan dengannya disebut sebagai
Policy.
▪ Suatu requester dapat mengirim pesan dengan menunjukkan bukti mengenai
claim yang dibutuhkan Web Service dengan menyertakan Security token
bersama dengan pesan tersebut. Jadi, pesan meminta tindakan tertentu kepada
service dan membuktikan bahwa pengirim pesan memiliki claim yang meminta
tindakan tersebut.
▪ Jika requester tidak memiliki claim yang dikehendaki,requester atau
seseorang yang mengatasnamakannya dapat mencoba memperoleh claim yang
diperlukan dengan mengkontak Web Service lain. Web Service ini, yang
disebut sebagai Security Token Service, dapat menghendaki sekumpulan claim.
Security token service bertindak sebagai perantara trust antara berbagai trust
domain yang berbeda dengan menyertakan Security token.
Model tersebut diilustrasikan pada gambar dibawah ini, dimana setiap
Requester dapat menjadi Security Token Service , dan Security Token Service dapat
menjadi Web Service, yang mengekspresikan Policy dan menghendaki Security token.
Gambar 4.1 - Model generik security messaging pada Web Service
Model generik messaging tersebut, yaitu claim, policy dan security token,
mendukung beberapa model yang lebih spesifik lainnya seperti halnya identity-
based security, access-control list, dan capabilities-based security. Model ini juga
mendukung teknologi yang ada saat ini seperti X.509 dan Karbero.
Page 20
17
4.2 SPESIFIKASI KEAMANAN WEB SERVICE
Spesifikasi Keamanan Web Service terdiri dari sekumpulan spesifikasi terpisah
yang dikembangkan secara hirarkis dan berlapis diatas protokol SOAP. Masing-
masing spesifikasi dikembangkan berdasarkan spesifikasi yang lain. Spesifikasi awal
keamanan Web Service terdiri dari :
▪ Message Security Model
▪ Web Service Endpoint Policy
▪ Trust Model
▪ Privacy Model
IBM dan Microsoft memberi nama masing-masing spesifikasi tersebut adalah
WS-Security (untuk message security model), WS-Policy (untuk Web Service end-
point policy), 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 spesifikasi awal
tersebut, kemudian dapat dikembangkan spesifikasi berikutnya yaitu secure
conversation (WS-SecureConversation), federated trust (WS-Federation), dan
otorisasi (WS-Authorization).
Struktur kerangka spesifikasi keamanan Web Service diilustrasikan seperti
gambar dibawah ini.
Gambar 4.2 – Arsitektur & Roadmap Spesifikasi Keamanan
untuk Web Service
Kombinasi spesifikasi keamanan tersebut memungkinkan adanya banyak
skenario yang akan sulit diimplementasikan jika menggunakan mekanisme keamanan
dasar yang ada saat ini.
Secara ringkas, spesifikasi keamanan tersebut dapat dijelaskan sebagai
berikut :
Spesifikasi Awal
• WS-Security : Menjelaskan bagaimana menerapkan XML signature dan XML
Encryption pada Header pesan SOAP, serta bagaimana menyertakan
security token, termasuk X.509, Karbero dan User Name/Password,
kedalam pesan SOAP.
• WS-Policy : menjelaskan kemampuan dan kendala dari security polici pada
level intermediate maupun end-point.
• WS-Trust : menjelaskan bagaimana framework trustu relationship antar
entitas bisnis
Page 21
18
• WS-Privacy : menjelaskan suatu model bagaimana Web Service dan requester
menyatakan privasi subyek yang diinginkan dan privasi organisasi.
Spesifikasi berikutnya
• WS-SecureConversation : menjelaskan bagaimana mengelola dan
memelakukan otentikasi pertukaran pesan
• WS-Federation : menjelaskan bagaimana mengintegrasikan berbagai
mekanisme manajemen identitas
• WS-Authorization : menjelaskan bagaimana data otorisasi dan authorization
policy.
Page 22
19
BAB V
STANDARD KEAMANAN WEB SERVICE
Kerentanan yang ada pada Web Service yang berbasis XML menjadi
pertimbangan utama yang mempengaruhui keragu-raguan para pengguna untuk
mengimplementasikan Web Service. Oleh Karena itu diperlukan standard teknologi
keamananan Web Service untuk mendukung keamanan penerapan Web Service secara
luas. Walaupun demikian, standard yang ada saat ini seperti LDAP, PKI, SSL/TSL
tetap memegang peranan penting untuk mengamankan Web Service dalam konteks
point-to-point.
Beberapa lembaga/organisasi profit maupun non-profit telah berupaya
untuk mengembangkan standard keamanan XML dan Web Service. Diantara
lembaga/organisasi tersebut, hingga saat ini ada 2 lembaga yang menjadi referensi
dalam penetapan standard keamanan XML Web Service yaitu W3C dan OASIS.
Tabel berikut ini menunjukkan beberapa standard keamanan XML Web Service yang
telah dan sedang ditetapkan oleh kedua organisasi tersebut [10] :
Standard
Standard
Body
Status
Deskripsi
XML Digital Signature
(XDSIG)
W3C
Completed Protokol untuk menandai isi
dokumen digital.
Memberikan aspek integri
tas data, dan non-repudia
tion
XML Encryption
(XENC)
W3C
Completed Protokol untuk mengeng-
kripsi dan dekripsi isi
dokumen digital.
XML Key Management
Specification
(XKMS)
W3C
Working
Draft
Protokol untuk mendistri
busikan dan me-registrasi
public key
Security Assertion Markup
Language
(SAML)
OASIS
Open
Standard
Menyediakan kerangka
XML untuk Web Service
yang mendukung pertukar
an otentikasi dan otorisasi
informasi antara partner
bisnis
Extensible Access Control
Markup Language
(XACML)
OASIS
Open
Standard
Spesifikasi XML untuk
mengekspresikan Policy
tentang akses informasi
melalui Internet.
WS-Security
OASIS
Working
Draft
Sekumpulan standard untuk
mengamankan pesan
SOAP pada aspek integrity
dan confidential- lity
Dalam bab ini fokus pembahasan hanya pada standard WS-Security yang
menjadi referensi penting bagi penerapan XML Web Service, dengan pertimbangan
sebagai berikut :
Page 23
20
• WS-Security akan menjadi referensi standard keamanan Web Service oleh
berbagai pihak (user, vendor, organisasi lainnya).
• WS-Security tidak menspesifikasikan standard keamanan tertentu yang
berbeda, tetapi memanfaatkan berbagai standard keamanan lain, seperti
X.509, Karberos, XML Digital Signature, XML Encryption, SAML, XKMS,
dls.
• WS-Security independent terhadap teknologi keamanan pada layer transport.
Standard keamanan pada level transport seperti SSL/TLS, Karberos, X.509,
LDAP, dls sudah banyak dibahas pada berbagai literature yang membahas
keamanan aplikasi berbasis Web pada umumnya, sehingga tidak dibahas secara
detail dalam bab ini.
• WS-Security merupakan implementasi dari model arsitektur keamanan Web
Service seperti yang dibahas pada Bab III.
5.1 SPESIFIKASI WS-Security
WS-Security atau juga dikenal sebagai Web Service Security Core Language
(WSS-Core) merupakan spesifikasi keamanan Web Service yang mendefinisikan
mekanisme pengamanan pada level pesan SOAP untuk menjamin message integrity &
confidentiality.
Standard WS-Security saat ini dikembangkan secara resmi oleh OASIS
berdasarkan spesifikasi yang diusulkan oleh Microsoft, IBM, dan VerySign pada 11
April 2002. Selanjutnya, OASIS melalui Web Service Security Technical Committee
(WSS) melanjutkan pengembangan WS-Security dengan menetapkan beberapa
spesifikasi teknis terpisah, seperti Core Specification, SAML Profile, XMrL Profile,
X.509 Profile, dan Karberos Profile.
Produk WSS untuk Core Specification (WSS-Core) adalah WSS: Soap Message
Security. Spesifikasi lain yang merupakan bagian dari Core Specification ini adalah
WSS: User Name Token Profile dan WSS: X.509 Certificate Token Profile.
Disamping 2 organisasi tersebut, ada organisasi lain yang juga aktif
mengembangkan standard keamanan Web Service yang disponsori oleh Sun
Microsystem yaitu Liberty Alliance Technology Group. Namun pada akhirnya
lembaga ini juga mengumumkan untuk memfokuskan diri pada pengembangan
spesifikasi WS-Security dan berkerjasama dengan OASIS untuk maksud tersebut.
Dengan demikian, WS-Security akan menjadi standard de-facto untuk pengamanan
Web Service.
5.1.1 Konsep dasar WS-Security
Secara umum standard WS-Security (versi orisinal) mendefinisikan suatu
spesifikasi mengenai bagaimana mengamankan pesan SOAP secara end-to-end,
dengan cara menyertakan (attach) digital signature, enkripsi dan security token
pada bagian Header dari pesan SOAP. Spesifikasi WSS-Core versi terbaru
menyediakan 3 mekanisme untuk memproteksi pesan dari ancaman terhadap upaya
gangguan keamanan pesan SOAP, yaitu (1)Kemampuan untuk mengirim security
token sebagai bagian dari pesan SOAP, (2) Message integrity dan (3) Message
confidentiality. Namun demikian, mekanisme tersebut tidak memberikan solusi
keamanan yang lengkap untuk Web Service. Spesifikasi ini merupakan building
block yang digunakan untuk mengakomoda- sikan berbagai variasi model keamanan
dan teknologi kemanan.
Dengan kata lain, WS-Security tidak menspesifikasikan suatu mekanisme
keamanan baru, tetapi menyediakan fleksibilitas untuk menggunaan teknologi
keamanan yang sudah ada (X.509, Karberos, XML Encryption), sehingga dapat
Page 24
21
mengakomodasi berbagai pendekatan keamanan secara umum. Hal baru yang
ditambahkan oleh WS-Security adalah suatu spesifikasi untuk menerapkan
mekanisme keamanan yang sudah ada (existing) tersebut kedalam pesan SOAP.
5.1.2 Mekanisme Proteksi Pesan
Secara umum struktur pesan Format SOAP yang mengimplementasikan WS-
Security terdiri dari : Envelop, Header dan Body seperti digambarkan sebagai
berikut :
Gambar 5.1- Diagram Struktur Pesan SOAP
Spesifikasi keamanan Web Service diterapkan pada bagian Header dan/atau
Body dari pesan SOAP. WSS-Core menspesifikasikan model keamanan pesan dalam
dalam bentuk security token yang digabung dengan teknologi digital signature untuk
melindungi dan meng-otentikasi pesan SOAP. Security Token menyediakan
mekanisme untuk membuktikan informasi mengenai key dari Pengirim. Namun
demikian, spesifikasi ini tidak mendefinisikan metode khusus untuk melakukan
otentikasi, tetapi hanya menunjukkan bahwa security token dapat diterapkan dalam
pesan SOAP. Deklarasi security token dapat disyahkan oleh Otorisator ataupun tidak
perlu disyahkan. Security token yang perla pengesahan disebut signed security token.
Contoh penggunaan signed security token adalah X.509 Certificate dan Karberos.
Security token yang tidak perlu pengesahan (unsigned security token) memerlukan
mekanisme untuk menolak atau menerima pesan bersarkan kepercayaan pada
informasi atau pengetahuan yang disertakan pada pesan tersebut. Contoh unsigned
security token ini adalah penggunaan User name/Password.
Signature digunakan untuk memverifikasi keaslian dan integritas pesan.
Signature juga dapat digunakan oleh Pengirim untuk menunjukkan kunci yang
digunakan untuk menkonfirmasi claim yang ada dalam security token, sehingga
memberikan identitas pada pesan tersebut.
WSS-Core menspesifikasikan proteksi pesan dengan menerapkan enkripsi dan
digital signature pada Header dan/atau Body dari pesan SOAP untuk menjamin
integritas dan kerahasiaan pesan. Integritas pesan diberikan dengan menerapkan
XML Signature bersamaan dengan security token untuk menjamin bahwa modifikasi
terhadap pesan dapat diteksi. Semnetara itu, kerahasiaan pesan diberikan dengan
Page 25
22
menerapkan
XML Encryption
bersamaan dengan
security token
untuk
mempertahankan kerahasiaan bagian pesan SOAP.
5.1.3 Security Header
Setiap pesan SOAP mempunyai suatu Penerima yang bertindak sebagai
penerima pesan dan merespon pesan. WS-Security versi original menyebut penerima
sebagai Aktor. Sehingga, setiap pesan SOAP paling tidak mempunyai satu Aktor,
yaitu orang bertindak berdasarkan pada pesan SOAP tersebut. Suatu pesan dapat
mempunyai lebih dari satu Aktor jika melalui sederetan node intermediary, seperti
yang akan dijelaskan pada spesifikasi WS-Routing.
Informasi yang berhubungan dengan keamanan pesan SOAP disertakan
(attach) pada bagian Header dari SOAP, tepatnya dalam blok yang diawali dengan
tag <Security>. Blok <Security> ini menyediakan mekanisme untuk menyertakan
informasi yang berkaitan dengan keamanan pada penerima tertentu, dan
dispesifikasikan oleh atribut Actor. Contoh syntax Header pada pesan SOAP menurut
versi WS-Security versi orisinal ditunjukkan pada gambar dibawah ini.
Gambar 5.2 - Struktur syntax Pesan SOAP (versi orisinal)
Untuk setiap target Penerima yang berbeda, informasi yang berkaitan dengan
keamanan harus dituliskan dalam elemen Security Header yang berbeda. Sehingga
Security Header dapat muncul beberapa kali dalam pesan SOAP. Dalam
perjalanannya, satu atau lebih Header baru dapat ditambahkan jika diperlukan
penambahan Target Penerima baru yang belum dispesifikasikan. Atribut Actor dalam
setiap Security Header mengidentifikasikan siapa yang menerima informasi
keamanan tersebut. Jika atribut Actor
tidak disebutkan, elemen Security Header
dapat dikonsumsi oleh setiap orang, tetapi tidak dapat dihapus sampai mencapai
tujuan akhirnya. Elemen Security Header juga menunjukkan tahapan ekripsi dan
penandatanganan yang dilakukan oleh Pengirim ketika membuat pesan SOAP.
Security Header ditambahkan pada pesan SOAP secara berurutan terhadap
elemen yang suda ada, untuk menjamin bahwa aplikasi penerima dapat memproses
setiap sub-elemen sesuai dengan urutan keberadaannya pada elemen Header. Namun
demikian, Spesifikasi WS-Security ini tidak menyebutkan secara khusus mode
pengurutan untuk pengolahan sub-elemen tersebut, sehingga aplikasi Penerima dapat
menggunakan apapun Policy yang diperlukan.
Dalam spesifikasi terbaru WSS-Core (WSS: SOAP Message Security) yang
ditetapkan OASIS Web Service Security TC (WSS), atribut untuk aktor ini didiganti
<S:Envelope>
<S:Header>
...
<Security S:actor="..." S:mustUnderstand="...">
...
</Security>
...
</S:Header>
...
</S:Envelope>
Page 26
23
dengan atribut role, dan spesifikasi Security Header terbaru menjadi sebagai
berikut :
Gambar 5.3- Struktur syntax Pesan SOAP (versi WSS Core)
Elemen Security yang dapat dimasukkan dalam Security Header pada pesan
SOAP antara lain adalah :
• User Name Token
• Binary Security Token (misalnya untuk X.509 Certificate dan Karberos)
• XML Token (SecurityTokenReference)
• ds:KeyInfo
• ds:Signature
• XML Encryption
• TimeStamp
Contoh penggunaan security token, signature dan encryption sesuai dengan
spesifikasi WSS-Core secara lengkap dapat dilihat berikut ini :
(001) <?xml version="1.0" encoding="utf-8"?>
(002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
(003) <S:Header>
(004) <wsse:Security>
(005)
<wsu:Timestamp>
(006)
<wsu:Created
(007)
wsu:Id="T0">2001-09-13T08:42:00Z</wsu:Created>
(008)
</wsu:Timestamp>
(009)
(010)
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
wsu:Id="X509Token"
EncodingType="wsse:Base64Binary">
(011)
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
(012)
</wsse:BinarySecurityToken>
(013)
<xenc:EncryptedKey>
(014)
<xenc:EncryptionMethod Algorithm=
<S:Envelope>
<S:Header>
...
<wsse:Security S:role="..."
S:mustUnderstand="...">
...
</wsse:Security>
...
</S:Header>
...
</S:Envelope>
Page 27
24
"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
(015)
<ds:KeyInfo>
(016)
<wsse:KeyIdentifier EncodingType="wsse:Base64Binary"
ValueType="wsse:X509v3">MIGfMa0GCSq...
(017)
</wsse:KeyIdentifier>
(018)
</ds:KeyInfo>
(019)
<xenc:CipherData>
(020)
<xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
(021)
</xenc:CipherValue>
(022)
</xenc:CipherData>
(023)
<xenc:ReferenceList>
(024)
<xenc:DataReference URI="#enc1"/>
(025)
</xenc:ReferenceList>
(026)
</xenc:EncryptedKey>
(027)
<ds:Signature>
(028)
<ds:SignedInfo>
(029)
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(030)
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(031)
<ds:Reference URI="#T0">
(032)
<ds:Transforms>
(033)
<ds:Transform
(34)
</ds:Transforms>
(035)
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(036)
<ds:DigestValue>LyLsF094hPi4wPU...
(037)
</ds:DigestValue>
(038)
</ds:Reference>
(039)
<ds:Reference URI="#body">
(040)
<ds:Transforms>
(041)
<ds:Transform
(042)
</ds:Transforms>
(043)
<ds:DigestMethod
(044)
<ds:DigestValue>LyLsF094hPi4wPU...
(045)
</ds:DigestValue>
(046)
</ds:Reference>
(047)
</ds:SignedInfo>
(048)
<ds:SignatureValue>
(049)
Hp1ZkmFZ/2kQLXDJbchm5gK...
(050)
</ds:SignatureValue>
(051)
<ds:KeyInfo>
(052)
wsse:SecurityTokenReference>
(053)
<wsse:Reference URI="#X509Token"/>
(054)
</wsse:SecurityTokenReference>
(055)
</ds:KeyInfo>
(056)
</ds:Signature>
(057)
</wsse:Security>
(058) <S:Header>
(059) <S:Body wsu:Id="body">
Page 28
25
(060)
<xenc:EncryptedData
Type="http://www.w3.org/2001/04/xmlenc#Element"
wsu:Id="enc1">
(061)
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
(062)
<xenc:CipherData>
(063)
<xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
(064)
</xenc:CipherValue>
(065)
</xenc:CipherData>
(066)
</xenc:EncryptedData>
(067) </S:Body>
(068) </S:Envelope>
5.2 SKENARIO PENGGUNAAN WS-Security
Mekanisme WS-Security dapat diterapkan untuk mengatasi berbagai isu
keamanan. Berikut ini adalah beberapa contoh skenario untuk mendukung
implementasi WS-Security berdasarkan usulan oleh IBM dan Microsoft dalam
dokumen ‘WS-Security AppNotes’ (15 Agustus 2002), yaitu :
▪ Direct Trust using User Name/Password – skenario ini mengilustrasikan
proses otentikasi menggunakan User Name dan Password dengan transport-
level security
▪ Direct Trust using Security Token- skenario ini mengilustrasikan direct trust
menggunakan X.509 certificate dan Karberos service ticket.
▪ Security Token Acquisition – skenario ini mengilustrasikan otentikasi
menggunakan security token
▪ Firewall Processing - skenario ini mengilustrasikan bagaimana firewall dapat
mendukung WS-Security dengan derajat kendali yang besar.
▪ Issued Security Token - skenario ini mengilustrasikan mekanisme otentikasi
dasar
Direct Trust using User Name/Password
Server dimana Web Service berada menggunakan pasangan public key untuk
menjamin keamanan kanal antara server dan client melalui koneksi HTTP dengan
menggunakan SSL/TSL. Requester membuka koneksi ke Web Service dengan
menggunakan transport-level security (SSL/TSL), dimana Requester mengirimkan
pesan permintaan dengan menyertakan security token yang berisi user name dan
password. Sementara Web Service meng-otentikasi informasi yang terdapat dalam
pesan, memproses request dan merespon hasilnya.
Dalam skenario ini integritas dan kerahasiaan pesan ditangani dengan
menggunakan mekanisme keamanan berbasis transport-layer.
Page 29
26
Contoh pesan SOAP yang dikirim dari Requester ke Web Service pada scenario
ini adalah sebagai berikut :
(001) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope">
(002)
<S:Header>
(003)
<wsse:Security
S:mustUnderstand="1">
(004)
<wsse:UsernameToken>
(005)
<wsse:Username>Zoe</wsse:Username>
(006)
<wsse:Password>ILoveDogs</wsse:Password>
(007)
</wsse:UsernameToken>
(008)
</wsse:Security>
(009)
</S:Header>
(010)
<S:Body>
(011)
<m:GetLastTradePrice xmlns:m="http://fabrikam123.com/">
(012)
<symbol>DIS</symbol>
(013)
</m:GetLastTradePrice>
(014)
</S:Body>
(015) </S:Envelope>
Direct Trust using Security Token
Skenario ini mengilustrasikan penggunaan security token yang secara langsung
dipercaya valid (trusted) oleh Web Service. Dalam hal ini, direct trust berarti bahwa
security token dikenal dan diverifikasi oleh Web Service. Skenario ini menganggap
bahwa Requester dan Web Service telah menggunakan beberapa mekanisme untuk
menetapkan trust relationship dalam menggunakan security token. Dengan kata lain,
kedua belah pihak memahami dengan baik policy untuk privacy masing-masing.
Requester mengirim pesan ke Web Service dengan dengan menyertakan
security token, dan memberikan proof-of-possession (public/private key) terhadap
security token menggunakan digital signature. Service melakukan verifikasi terhadap
public/private key dan mengevaluasi security token, memproses permintaan dan
mengembalikan hasil pemrosesannya.
Page 30
27
(001) <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
(002) <S:Header>
(003)
<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">
(004)
<m:action>http://fabrikam123.com/getQuote</m:action>
(005)
<m:to>http://fabrikam123.com/stocks</m:to>
(006)
<m:from>mailto:johnsmith@fabrikam123.com</m:from>
(007)
<m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
(008)
</m:path>
(009)
<wsse:Security
(010)
EncodingType="wsse:Base64Binary"
wsu:Id="X509Token"
ValueType="wsse:X509v3">
(011)
MIIDQTCCAqqgAwIBAgICAZIhvcNAQEFBQAwTjELMAkGA1UEBhMCS...
(012)
(013)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
(014)
<SignedInfo>
(015)
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-
exc-c14n#"/>
(016)
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-
sha1"/>
(017)
<Reference URI="">
(018)
<Transforms>
(019)
<Transform Algorithm="http://...#RoutingTransform"/>
(020)
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-
c14n#"/>
(021)
</Transforms>
(022)
<DigestMethod
(023)
<DigestValue>yH8GsCH3FT747UhqqzHqqSTj7CM=</DigestValue>
(024)
</Reference>
(025)
</SignedInfo>
(026)
<SignatureValue>
(027)
TQtb/T9NTGgRzbtDCctfw0SKY7/PHVZtPMFoLtPCixU3Kobis/Q...
(028)
</SignatureValue>
(029)
<KeyInfo>
(030)
<wsse:SecurityTokenReference>
(031)
<wsse:Reference URI="#X509Token"/>
(032)
(033)
</KeyInfo>
(034)
</Signature>
(035)
</wsse:Security>
(036) </S:Header>
(037)
<S:Body>
(038)
<m:GetLastTradePrice xmlns:m="http://www.fablikam123.com/">
(039)
(040)
(041) </S:Body>
(042) </S:Envelope>
Page 31
28
Security Token Acquisition
Dalam skenario ini, security token tidak terdapat dalam pesan SOAP,
melainkan menggunakan mekanisme security token reference untuk mencari dan
mengambil token. Requester mengirim pesan ke service dengan menyebutkan
referensi terhadap keberadaan security token, dan menyediakan proof-of-possession
dalam bentuk XML Signature. Web Service menggunakan informasi yang ada pada
security token reference untuk memperoleh security token dari security token service
dan memvalidasi private/public key (proof). Web Service menerima (trusted)
security token, sehingga request diproses dan dikembalikan hasilnya ke requester.
xmlns:S="http://www.w3.org/2001/12/soap-envelope">
(002) <S:Header>
(003)
(004)
(005)
(006)
(007)
(008)
</m:path>
(009)
<wsse:Security
(010)
<wsse:SecurityTokenReference wsu:Id="token1">
(011)
<wsse:Reference URI="ldap://fabrikam123.com/CN=John..."/>
(012)
(013)
(014)
<SignedInfo>
(015)
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-
c14n#"/>
(016)
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-
sha1"/>
(017)
<Reference URI="">
(018)
<Transforms>
(019)
<Transform
Algorithm="http://...#RoutingTransform"/>
(020)
<Transform
(021)
</Transforms>
Page 32
29
(022)
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(023)
<DigestValue>yH8G3FT747UhqqzHqqSTj7CM=</DigestValue>
(024)
</Reference>
(025)
</SignedInfo>
(026)
<SignatureValue>
(027)
TQtb/+yR56T9NTGgRzbtDCctfw0SKY7/Pq2FoLtPCixU3Kobis/Q...
(028)
</SignatureValue>
(029)
<KeyInfo>
(030)
(031)
<wsse:Reference URI="#token1"/>
(032)
(033)
</KeyInfo>
(034)
</Signature>
(035)
</wsse:Security>
(036) </S:Header>
(037) <S:Body>
(038)
<m:GetLastTradePrice xmlns:m="http://www.foo.com/">
(039)
(040)
(041)
</S:Body>
(042) </S:Envelope>
Firewall Processing
Firewall melakukan evaluasi terhadap pesan SOAP yang datang, dan hanya
mengijinkan pesan yang berasal dari requester yang telah diotorisasi untuk melewati
Firewall. Dalam skenario ini, Firewall membuat keputusan dengan mengevaluasi
security token yang digunakan untuk menandatangani pesan.
Dalam skenario yang lain, Firewall dapat juga bertindak sebagai security token
yang meminta otoritas dan hanya mengijinkan pesan yang memiliki proof-of-
possession (private/public key) terhadap security token yang diminta oleh Firewall.
Contoh pesan SOAP yang dikirim dari Requester ke Web Service pada skenario
Page 33
30
(001) <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
(002) <S:Header>
(003)
(004)
(005)
(006)
<m:fwd>
(007)
<m:via>http://firewall.fabrikam123.com/</m:via>
(008)
</m:fwd>
(009)
(010)
(011)
</m:path>
(012)
<wsse:Security
S:actor="http://firewall.fabrikam123.com/"
(013)
wsu:Id="X509Token4Firewall"
(014)
MIIDQTCCAqqgAwIBAgICAQQwDQYJ...
(015)
(016)
(017)
<SignedInfo>
(018)
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-14n#"/>
(019)
<SignatureMethod
(020)
<Reference URI="">
(021)
<Transforms>
(022)
<Transform Algorithm="http://...#RoutingTransform"/>
(023)
<Transform Algorithm="http://www.w3.org/2001/10/xml-
exc-c14n#"/>
(024)
</Transforms>
(025)
<DigestMethod
(026)
<DigestValue>yH8GsCH3FTqzHqqSTj7CM=</DigestValue>
(027)
</Reference>
(028)
</SignedInfo>
(029)
<SignatureValue>
(030)
f5JJPvwToxNBBzy5R3om/ZtTK63jw...
(031)
</SignatureValue>
(032)
<KeyInfo>
(033)
(034)
<wsse:Reference URI="#X509Token4Firewall"/>
(035)
(036)
</KeyInfo>
(037)
</Signature>
(038)
</wsse:Security>
(39)
<wsse:Security
Page 34
31
(040)
wsu:Id="X509Token4Stockquote"
(041)
MIIDQTCCAqqgAwIBAgICAQQwDQYJKoZIhvcNAQEF...
(042)
(043)
(044)
<SignedInfo>
(045)
<CanonicalizationMethod
(046)
<SignatureMethod
(047)
<Reference URI="">
(048)
<Transforms>
(049)
<Transform
Algorithm="http://...#RoutingTransform"/>
(050)
<Transform
(051)
</Transforms>
(052)
<DigestMethod
(053)
<DigestValue>yH8GsCH3FT7qqSTj7CM=</DigestValue>
(054)
</Reference>
(055)
</SignedInfo>
(056)
<SignatureValue>
(057)
OZ21MKnCQi2Jglw2qIO5e1azezl/j0BP3h2Ut...
(058)
</SignatureValue>
(059)
<KeyInfo>
(060)
(061)
<wsse:Reference URI="#X509Token4Stockquote"/>
(062)
(063)
</KeyInfo>
(064)
</Signature>
(065)
</wsse:Security>
(066)
</S:Header>
(067)
<S:Body>
(068)
m:GetLastTradePrice xmlns:m="http://www.fabrikam123.com/">
(069)
(070)
(071) </S:Body>
(072) </S:Envelope>
Page 35
32
Issued Security Token
Skenario ini hampir sama dengan Security Token Acquisition, kecuali bahwa
security token dikirim ke Requester dari Security Token Service , kemudian pesan
permintaan dikirim ke Web Service dengan menyertakan security token tersebut
menggunakan elemen <BinarySecurityToken>. Security token dapat berupa X.509
atau Karberos. Sekali security token dikirim oleh Secuirty token service, security
token tersebut dapat digunakan beberapa kali oleh, misalnya untuk Web Service yang
berbeda jika token yang dikirim mengijinkan hal tersebut.
Page 36
33
BAB VI
KESIMPULAN
Arsitektur dan teknologi Web Service sangat rentan terhadap upaya
gangguan keamanan dari pihak-pihak yang tidak 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 itu standard keamanan yang ada saat ini seperti
SSL/TSL tidak cukup memadai, walaupun masih memegang peranan penting,
jika 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 stándard keamanan Web Service yang ada,
WS-Security menyediakan arstitektur 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-Security menjamin integritas data dan kerahasiaan (confidentiality) dengan
mengimplementasikan teknologi XML Signature dan XML Encryption.
Disamping itu, WS-Security menerapkan konsep mengenai secure messaging
dengan menggunakan security token untuk mengimplementasikan teknologi
kemanan yang ada seperti C.509 certificate maupun Karberos akan
memberikan jaminan pada aspek otentitas 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
jika dikaitkan dengan aspek perfomansi sistem akan menjadi pertimbangan
yang dilematis bagi pengguna maupun pengembang perangkat lunak yang akan
menggunakan teknologi Web Service.
)OoO(
Page 37
DAFTAR PUSTAKA
[1] Andrew Yang, “Implement Web Service Securely”, .NET Magazine, Technical
Edition, 2003. Available :
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.
Page 38
[14] Mark O’Neill, “Architecting Security for Web Service”, JAVAPro, Agustus
2003. Available :
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 Manager’s Guide to XML Web Service Security”, 6
Januari 2003. Available : http://www.westbridgetech.com

Webservice

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Webservice

Diunggah oleh

Hak Cipta:

Format Tersedia

This is the html version of the file http://www.cert.or.

TINJAUAN ASPEK KEAMANAN

Anda mungkin juga menyukai