Security Concerns pada SOA
- Secure communication — pertukaran pesan antara service & klien harus aman.
- Trust establishment:
- Bagaimana klien tahu service benar melakukan yang dijanjikan? (Service bisa ditemukan saat runtime — tidak ada kesempatan verifikasi sebelumnya.)
- Bagaimana service tahu klien berwenang memakainya?
Karena pendekatan yang dipakai adalah mengimplementasikan SOA lewat web service, maka SOA security pada dasarnya = web service security.
- Tiga spesifikasi inti: WS-Security, XML-Signature, XML-Encryption. WS-* Security adalah generasi kedua teknologi keamanan SOA.
- Single Sign-On (SSO) — mekanisme keamanan tersentralisasi yang melengkapi ekstensi WS-Security.
- Spesifikasi terkait lainnya: WS-SecurityPolicy, WS-Trust, WS-SecureConversation, WS-Federation, XACML, XML Key Management, XML Signature, SAML, .NET Passport, SSL, WS-I Basic Security Profile.
Basic Components of SOA Security
| Komponen | Penjelasan |
|---|---|
| Identification | Service requestor menyatakan asal/pemilik dirinya (making a claim) sebelum mengakses service aman |
| Authentication | Pesan yang diterima harus membuktikan benar berasal dari pengirim yang diklaim |
| Authorization | Setelah terautentikasi, ditentukan apa yang diizinkan dilakukan requestor |
| Single Sign-On | Didukung LDAP, SAML, Kerberos, .NET Passport, XACML — bisa mulus untuk semua service atau individual per service |
| Confidentiality & Integrity | Confidentiality = privasi konten pesan; Integrity = memastikan pesan tidak diubah |
| Transport level vs Message level | Transport level via SSL (mengamankan HTTP); Message level via XML-Encryption & XML-Signature |
WS-* Security Standards Framework
Kerangka berlapis (layered) dan bisa dikomposisikan (composable):
| Layer | Standar |
|---|---|
| Security Management | XKMS, WS-Trust |
| Identity Management | WS-Federation, Liberty, SAML |
| Message Security | WS-Security, WS-SecureConversation |
| Reliable Messaging | WS-ReliableMessaging |
| Policy & Access Control | WS-Policy, XACML, SAML |
| SOAP Foundation | — |
| XML Security | XML-Encryption, XML-Signature |
| Transport Level Security | SSL/TLS |
| Network Level Security | IPSec |
Teori vs praktik: kerangka ini idealnya berlapis, tiap standar layer atas re-use & extend spesifikasi layer bawahnya. Praktiknya: spesifikasi dari badan berbeda tidak selalu kompatibel; kepatuhan pada profile meningkatkan interoperabilitas; implementasi vendor berbeda tidak selalu interoperable.
Isu performa: XML menyebabkan overhead. Solusi packaging binary data efisien: XOP (XML-binary Optimized Packaging), MTOM (SOAP Message Transmission Optimization Mechanism), RRSHB. Untuk enkripsi/dekripsi & manajemen signature: XML accelerators & XML firewalls.
Terminologi Dasar
- Signature: nilai hasil komputasi kriptografis (kunci simetris/asimetris) terikat ke data sehingga penerima bisa memverifikasi data tidak berubah dan/atau berasal dari penandatangan.
- Claim: deklarasi oleh suatu entitas (nama, identitas, kunci, grup, privilege, kapabilitas, dst).
- Security Token: kumpulan (satu atau lebih) claim.
- Signed Security Token: security token yang ditegaskan (asserted) & ditandatangani kriptografis oleh otoritas tertentu (mis. sertifikat X.509, tiket Kerberos).
XML Encryption & XML Signature
- XML Encryption (W3C Recommendation, Des 2002) — menyediakan confidentiality untuk aplikasi yang bertukar data terstruktur: representasi standar resource terenkripsi, memisahkan info enkripsi dari data terenkripsi (dengan mekanisme referensi keduanya), menyediakan mekanisme penyampaian info kunci enkripsi, dan mendukung enkripsi sebagian/seluruh dokumen XML.
- XML Signature (W3C Recommendation, Feb 2002) — building block untuk banyak standar keamanan web service lain (mis. XKMS, WS-Security). Merepresentasikan tanda tangan digital sebagai elemen XML; data yang ditandatangani bisa beragam tipe & granularitas (dokumen XML, elemen XML, file data digital apa pun).
WS-Security
Web Services Security: SOAP Message Security (OASIS Standard, Feb 2006). Tujuan:
- Memberikan integritas & confidentiality untuk satu pesan SOAP, memakai mekanisme signature, enkripsi, dan token keamanan yang sudah ada.
- Menyediakan mekanisme mengasosiasikan security token dengan konten pesan (header & body).
- Ekstensibilitas — mendukung berbagai format token keamanan.
WS-Security menyediakan quality of protection lewat: message integrity, message confidentiality, single message authentication. Tidak spesifik ke satu jenis token — mendukung banyak format (X.509, Kerberos, dsb).
Penting: WS-Security sendiri tidak menjamin keamanan atau memberikan solusi keamanan lengkap. Ia adalah building block yang dipakai bersama protokol web service/aplikasi lain.
Goals & Non-Goals WS-Security
| Goals | Non-Goals |
|---|---|
| Mendukung banyak format token, trust domain, format signature, teknologi enkripsi | Membangun security context/mekanisme otentikasi (itu tugas WS-Trust) |
| Keamanan konten pesan end-to-end, bukan sekadar level transport | Derivasi kunci |
| Advertisement & pertukaran kebijakan keamanan | |
| Bagaimana trust ditentukan | |
| Non-repudiation |
Contoh Struktur SOAP Message Security
<soap:Envelope>
<soap:Header>
<ws:Security>
<ws:BinarySecurityToken id="X509token" ValueType="X.509">...</ws:BinarySecurityToken>
<ds:Signature>
<ds:Reference><ds:Ref URI="#PO"/></ds:Reference>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo><ws:BinarySecurityTokenReference URI="#X509token"/></ds:KeyInfo>
</ds:Signature>
</ws:Security>
</soap:Header>
<soap:Body>
<po:PurchaseOrder ID="PO"/>
</soap:Body>
</soap:Envelope>Mekanisme & Peringatan WS-Security
- Integrity — digital signature & sertifikat.
- Confidentiality — XML Encryption.
- Digital signature saja tidak cukup untuk otentikasi pesan — perlu dikombinasikan dengan timestamp/sequence number untuk mencegah replay attack.
- Verifikasi identitas pengirim butuh bukti kepemilikan private key (mis. lewat protokol challenge-response).
- Kombinasi signing + encryption pada data yang sama bisa memunculkan kerentanan kriptografis (mis. mengenkripsi data yang sudah ditandatangani tapi membiarkan tanda tangannya clear → rentan plain text guessing attack).
WS-Policy
Web Services Policy Framework (W3C, status Recommendation 2007). Tujuan: menawarkan mekanisme merepresentasikan kapabilitas & kebutuhan web service sebagai Policy.
- Policy: dipakai menyampaikan kondisi interaksi antara dua endpoint web service; provider memaparkan policy (kondisi menyediakan service), requester memakainya untuk memutuskan pakai atau tidak.
- Framework untuk mendeskripsikan kebijakan, bukan mengelolanya.
Model Policy
| Elemen | Definisi |
|---|---|
| Policy | Koleksi policy alternative (tidak berurutan) |
| Policy Alternative | Koleksi policy assertion (semua harus dipenuhi — “do all”); alternatif saling eksklusif (exclusive OR — “pick one”) |
| Policy Assertion | Kebutuhan/kapabilitas individual dari suatu perilaku, mis. token yang didukung |
| Policy Assertion Parameter | Mengualifikasi perilaku dari suatu assertion |
| Policy Vocabulary | Set semua policy assertion type yang dipakai |
| Policy Subject / Scope / Attachment | Entitas tempat policy melekat (endpoint, message, dst) dan mekanisme mengasosiasikannya |
WS-PolicyAssertions mendefinisikan generic policy assertions; WS-PolicyAttachment mengasosiasikan policy dengan service (embed langsung di WSDL atau via UDDI); WS-SecurityPolicy mendefinisikan assertion keamanan sesuai klaim WS-Security (integritas, confidentiality, token pesan).
XACML (eXtensible Access Control Markup Language)
Standar berbasis XML (OASIS, 2005) untuk kontrol akses granular — mendeskripsikan bahasa policy dan bahasa request/response keputusan kontrol akses. Sintaks berbasis triple <Object, Subject, Action>; mendukung negative authorization (penolakan eksplisit); konsisten & dibangun di atas SAML.
Komponen XACML Protocol
| Komponen | Peran |
|---|---|
| PAP (Policy Administration Point) | Membuat & menyimpan kebijakan keamanan |
| PEP (Policy Enforcement Point) | Melakukan kontrol akses — membuat decision request & menegakkan keputusan otorisasi |
| PIP (Policy Information Point) | Sumber nilai atribut / data yang dibutuhkan evaluasi policy |
| PDP (Policy Decision Point) | Mengevaluasi policy yang berlaku & memberikan keputusan otorisasi |
PEP dan PDP mungkin berada di aplikasi yang sama, atau tersebar di server berbeda.
Response XACML: Permit, Permit with Obligations, Deny, NotApplicable (tidak ada policy yang cocok), Indeterminate (error evaluasi).
XACML data flow model: access requester mengirim access request ke PEP; PEP meneruskan request ke context handler yang berkoordinasi dengan PDP (evaluasi policy dari PAP), PIP (atribut subject/resource/environment), dan resource — hingga context handler mengembalikan response context ke PEP yang menegakkan keputusan (+obligations) ke access requester.
XACML Policy terdiri dari 4 komponen: target, rule-combining algorithm identifier, kumpulan rules, dan obligations. Tiap rule punya: target, effect (permit/deny), dan condition. Target menentukan set resources, subjects, actions, environment tempat policy berlaku.
SAML (Security Assertion Markup Language)
Standar berbasis XML (OASIS SSTC, v2.0 disetujui 2005) untuk authentication & authorization — mempromosikan interoperabilitas antar sistem otentikasi/otorisasi berbeda, dengan mendefinisikan kerangka XML untuk mengkomunikasikan info keamanan/identitas lewat infrastruktur keamanan yang beragam (PKI, Kerberos, LDAP, dst).
Konsep Dasar SAML
| Entitas | Peran |
|---|---|
| SAML Authority / Identity Provider (IdP) | Membuat assertion SAML |
| Service Provider (SP) | Memakai assertion untuk memberi akses ke pengguna |
| Relying Party (RP) | Entitas yang mempercayai assertion (biasanya = SP) |
Jenis Assertion:
- Authentication — subjek telah diautentikasi dengan cara & waktu tertentu (“Martino authenticated with a password at 9:00am”).
- Attribute — subjek terkait atribut tertentu (“Bill is an account manager with $1000 spending limit”).
- Authorization decision — subjek diizinkan melakukan aksi tertentu (“John Doe is permitted to buy a specified item”).
Alur SAML (Single Sign-On)
sequenceDiagram participant U as End User Browser participant SP as Service Provider participant IdP as Identity Provider U->>SP: 1. Access service provider SP-->>U: 2. Redirect SAML request (SP-initiated) U->>IdP: 3. Relay SAML request IdP->>U: 4/5. Authenticate user, generate SAML assertion U->>SP: 6. Relay SAML assertion SP-->>U: 7. Security context (jika terautentikasi) U->>SP: 8. Request resource SP-->>U: 9. SP responds dengan resource
Perbandingan XACML, SAML, XKMS
| XACML | SAML | XKMS | |
|---|---|---|---|
| Fokus utama | Kontrol akses berbasis kebijakan | Autentikasi & otorisasi | Manajemen kunci & sertifikat |
| Standar | OASIS | OASIS | W3C |
| Komponen utama | PAP, PEP, PDP, PIP | IdP, SP, RP | X-KISS, X-KRSS |
| Use case umum | Kontrol akses granular | Single Sign-On (SSO) | Validasi kunci & sertifikat |
SSL/TLS dan IPsec (Transport & Network Level)
- SSL/TLS — menyediakan keamanan level transport untuk aplikasi web service: authentication, data integrity, data confidentiality; mengaktifkan sesi aman point-to-point.
- IPsec — keamanan level jaringan: sesi aman dengan host authentication, data integrity, data confidentiality.
XKMS (XML Key Management Specification)
Menyediakan interface berbasis web ke Public Key Infrastructure (PKI) yang sudah ada. Menspesifikasikan protokol untuk mendistribusikan dan meregistrasi kunci publik; cocok dipakai bersama XML-Signature & XML-Encryption.
Dua layanan:
- X-KISS (XML Key Information Service Specification) — menemukan & memvalidasi kunci publik.
- X-KRSS (XML Key Registration Service Specification) — mendaftarkan (register), memperbarui (reissue), mencabut (revoke), dan memulihkan (recover) kunci publik.
WS-Trust
Web Services Trust Language (Feb 2005) — ekstensi WS-Security yang menyediakan kerangka untuk meminta & menerbitkan security token, serta mem-broker hubungan trust:
- Metode menerbitkan, memperbarui, dan memvalidasi security token.
- Cara membangun, menilai keberadaan, dan mem-broker hubungan trust.
Motivasi: penerima pesan yang dilindungi WS-Security bisa punya 3 masalah dengan security token di dalamnya: Format (format token tidak dikenal), Trust (tidak bisa membangun chain-of-trust dari trust anchor-nya ke penerbit/penandatangan token), Namespace (tidak bisa memahami claim dalam token karena beda sintaksis).
Terminologi Trust
| Istilah | Arti |
|---|---|
| Trust | Karakteristik satu entitas bersedia mengandalkan entitas lain untuk menjalankan aksi/membuat assertion |
| Direct Trust | Relying party menerima langsung klaim dalam token yang dikirim requestor |
| Direct Brokered Trust | Satu pihak mempercayai pihak kedua yang, pada gilirannya, mempercayai/menjamin pihak ketiga |
| Indirect Brokered Trust | Pihak kedua bernegosiasi dengan pihak ketiga (atau lebih) untuk menilai trust pihak ketiga |
| Trust Engine | Komponen konseptual yang mengevaluasi aspek keamanan sebuah pesan |
Security Token Service (STS)
Web service yang menerbitkan security token, membuat assertion berdasarkan bukti yang dipercayainya, ke siapa pun yang mempercayainya (atau ke penerima spesifik). Untuk mengkomunikasikan trust, service butuh bukti (mis. signature). Sebuah service bisa membuat token sendiri atau bergantung pada STS terpisah — inilah dasar trust brokering. Interaksi memakai elemen <wst:RequestSecurityToken> dan <wst:RequestSecurityTokenResponse>.
Contoh kasus: klien memakai sertifikat X.509 tapi provider hanya memahami Kerberos, dan belum ada trust relationship sebelumnya — STS bertindak sebagai broker penerjemah format token.
Countermeasure man-in-the-middle attack: kunci kriptografis diturunkan dari keseluruhan pertukaran pesan, bukan sekadar token statis.
XML Accelerators & XML Firewalls
- XML Accelerators — hardware/software khusus untuk: parsing XML/SOAP, validasi skema XML, pemrosesan XPath, transformasi XSLT.
- XML Firewalls (a.k.a. XML Gateways) — melakukan fungsi accelerator + mendukung standar WS-Security + fungsi tambahan: filtering XML/SOAP berbasis konten/metadata, enkripsi/dekripsi pesan XML di level pesan/elemen, verifikasi & penandatanganan XML Signature, fungsi otentikasi & otorisasi.
WS-Federation
Mendefinisikan mekanisme untuk mengaktifkan federasi identity, account, attribute, authentication, dan authorization lintas trust realm berbeda. Mencakup pseudonym service yang menjaga informasi identitas alternatif untuk principal dalam suatu trust realm/federasi.
Proses pertukaran token biasanya di-bootstrap lewat sign-on untuk mendapat token keamanan awal, yang kemudian bisa diterima langsung oleh web service, atau ditukar di STS/Identity Provider untuk mendapat token keamanan tambahan.
Komponen ringkasan: Attribute Services ↔ IP/STS ↔ Pseudonym Services, dengan output Federated Sign-out Messages, Principal Management, Sign Out, dan Token requests.
Summary — Bahasa Standar WS-* Security
Poin penting: istilah dalam keamanan sering tidak berarti sepersis dugaan awam:
- WS-Security tidak mengatasi security secara umum, hanya proteksi kriptografis pesan SOAP.
- WS-Trust tidak mengatasi trust secara umum, hanya otentikasi (dan otorisasi).
- WS Security roadmap adalah kerangka mendeskripsikan bagaimana request seharusnya diotorisasi, tapi tidak menyediakan dasar konseptual untuk menganalisis kebijakan tersebut.
Flashcard
flashcards Sebutkan 5 komponen dasar SOA Security :: Identification, Authentication, Authorization, Single Sign-On, Confidentiality & Integrity (plus Transport-level vs Message-level security). Apa perbedaan Transport-level security dan Message-level security? :: Transport-level via SSL (mengamankan HTTP/koneksi); Message-level via XML-Encryption & XML-Signature (mengamankan konten pesan itu sendiri, end-to-end). Apa tujuan utama WS-Security, dan apa yang BUKAN tujuannya (non-goals)? :: Tujuan: message integrity, confidentiality, single message authentication, mendukung banyak format token/trust domain/signature/enkripsi, keamanan end-to-end. Non-goals: membangun security context/otentikasi (itu WS-Trust), key derivation, pertukaran kebijakan, penentuan trust, non-repudiation. Mengapa WS-Security TIDAK cukup untuk menjamin keamanan penuh? :: Karena WS-Security hanya building block untuk perlindungan kriptografis pesan SOAP — harus dipakai bersama protokol web service/aplikasi lain untuk solusi keamanan lengkap. Sebutkan 4 komponen XACML Protocol beserta perannya :: PAP (buat & simpan policy), PEP (tegakkan kontrol akses, buat decision request), PIP (sumber atribut untuk evaluasi), PDP (evaluasi policy & beri keputusan otorisasi). Apa 4 kemungkinan response dari XACML PDP? :: Permit, Permit with Obligations, Deny, NotApplicable (tidak ada policy cocok), Indeterminate (error evaluasi). Sebutkan 3 jenis SAML Assertion :: Authentication (subjek terautentikasi cara/waktu tertentu), Attribute (subjek terkait atribut tertentu), Authorization decision (subjek diizinkan melakukan aksi tertentu). Apa perbedaan Direct Trust dan Direct Brokered Trust pada WS-Trust? :: Direct Trust: relying party langsung menerima klaim token dari requestor. Direct Brokered Trust: satu pihak mempercayai pihak kedua yang menjamin/mempercayai pihak ketiga (via broker). Apa fungsi Security Token Service (STS) pada WS-Trust? :: Web service yang menerbitkan security token berdasarkan bukti yang dipercayainya; bisa jadi basis trust brokering ketika dua pihak memakai format token berbeda (mis. X.509 vs Kerberos) tanpa trust relationship sebelumnya. Apa perbedaan X-KISS dan X-KRSS pada XKMS? :: X-KISS (XML Key Information Service Specification) untuk menemukan & memvalidasi kunci publik; X-KRSS (XML Key Registration Service Specification) untuk mendaftarkan, memperbarui, mencabut, dan memulihkan kunci publik. Apa perbedaan XML Accelerator dan XML Firewall/Gateway? :: Accelerator: hardware/software untuk parsing XML/SOAP, validasi skema, XPath, XSLT. Firewall/Gateway: melakukan semua fungsi accelerator PLUS mendukung WS-Security, filtering konten, enkripsi/dekripsi, verifikasi signature, dan fungsi otentikasi/otorisasi. Apa fungsi WS-Federation dan pseudonym service di dalamnya? :: Mendefinisikan mekanisme federasi identity/account/attribute/authentication/authorization lintas trust realm berbeda; pseudonym service menjaga informasi identitas alternatif principal dalam suatu trust realm/federasi. Mengapa “WS-Trust tidak mengatasi trust secara umum” menurut kesimpulan materi? :: Karena WS-Trust sebenarnya hanya berkaitan dengan mekanisme otentikasi (dan otorisasi) — bukan konsep trust secara filosofis/umum.