Parser SAML

SAML (Security Assertion Markup Language) adalah standar berbasis XML untuk bertukar data autentikasi dan otorisasi antara penyedia identitas (IdP) dan penyedia layanan (SP). Alat ini mendekode pesan SAML dari URL, menangani enkoding Base64 dan kompresi DEFLATE, dan memformat XML untuk inspeksi.

Spesifikasi

• OASIS SAML 2.0 Core
• OASIS SAML 2.0 Bindings
• SAML 2.0 Technical Overview

Kasus Penggunaan Umum

• Men-debug alur autentikasi Enterprise Single Sign-On (SSO)
• Memeriksa assertion SAML dari penyedia identitas (Okta, Azure AD, ADFS)
• Memecahkan masalah integrasi SAML antar layanan
• Memverifikasi atribut assertion dan nilai NameID
• Menganalisis AuthnContext dan parameter sesi
• Mengaudit konfigurasi SAML untuk tinjauan keamanan

Fitur

• Mengurai pesan SAML AuthnRequest (SP ke IdP)
• Mendekode SAML Response dan Assertion (IdP ke SP)
• Mengekstrak SAMLRequest dan SAMLResponse dari parameter query URL
• Menangani enkoding Base64 dan kompresi DEFLATE (binding HTTP-Redirect)
• Memformat struktur XML dengan penyorotan sintaks
• Menampilkan ringkasan pesan (tipe, ID, IssueInstant, Destination, Status)
• Mengekstrak Issuer, Subject/NameID, dan Conditions
• Menampilkan atribut assertion dari AttributeStatement
• Indikator keberadaan tanda tangan

Contoh

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Tips

• SAML menggunakan dua binding utama: HTTP-Redirect (GET dengan deflate+base64) dan HTTP-POST (POST dengan base64).
• Parameter RelayState mempertahankan URL yang awalnya diminta selama alur SSO.
• Assertion SAML dapat ditandatangani, dienkripsi, atau keduanya. Alat ini menampilkan konten yang didekode.
• Periksa kondisi NotBefore dan NotOnOrAfter untuk memvalidasi waktu assertion.

Pemahaman Parser SAML

SAML (Security Assertion Markup Language) adalah standar terbuka berbasis XML untuk bertukar data autentikasi dan otorisasi antara Identity Provider (IdP) dan Service Provider (SP). SAML 2.0, dipublikasikan oleh OASIS pada tahun 2005, tetap menjadi protokol dominan untuk Enterprise Single Sign-On (SSO), memungkinkan karyawan untuk melakukan autentikasi sekali dan mengakses beberapa aplikasi.

Alur SAML SSO bekerja sebagai berikut: pengguna mencoba mengakses service provider, SP membuat AuthnRequest dan mengarahkan browser ke IdP, IdP mengautentikasi pengguna dan membuat SAML Response berisi Assertion, dan browser mengirim Response ini via POST kembali ke SP. Assertion berisi identitas pengguna (NameID), atribut (email, grup, peran), dan kondisi (jendela validitas, pembatasan audience).

Pesan SAML ditransportasikan menggunakan binding. Binding HTTP-Redirect mengkodekan XML menggunakan kompresi DEFLATE dan enkoding Base64 dalam parameter query URL. Binding HTTP-POST hanya menggunakan Base64 dan mengirim melalui formulir yang otomatis terkirim. Men-debug SAML memerlukan dekoding lapisan-lapisan ini untuk memeriksa XML yang mendasari.

Assertion SAML dapat ditandatangani (untuk membuktikan bahwa berasal dari IdP), dienkripsi (untuk mencegah perantara membaca isi), atau keduanya. Saat memecahkan masalah SSO, langkah pertama selalu mendekode SAML Response dan memeriksa kondisi, audience, timestamp, dan nilai atribut assertion.

SAML dan OAuth 2.0/OpenID Connect melayani tujuan yang berbeda. SAML dirancang untuk SSO enterprise menggunakan assertion berbasis XML yang ditransportasikan melalui pengalihan browser, dan paling umum di lingkungan enterprise dengan penyedia identitas seperti ADFS dan Okta. OAuth 2.0 adalah framework otorisasi untuk akses API menggunakan token JSON, dan OpenID Connect menambahkan lapisan autentikasi di atas OAuth menggunakan JWT. OIDC lebih umum di aplikasi web dan mobile modern, sementara SAML tetap dominan di lingkungan TI korporat.

Pesan SAML sering muncul sebagai string yang tidak dapat dipahami karena dikodekan untuk transportasi. Pada binding HTTP-POST, XML dikodekan dalam Base64. Pada binding HTTP-Redirect, XML pertama dikompresi DEFLATE, kemudian dikodekan Base64, lalu dikodekan URL. Membaca XML asli memerlukan pembalikan lapisan-lapisan ini dalam urutan yang benar. Alat ini menangani semua langkah dekoding secara otomatis terlepas dari binding mana yang digunakan.

Saat memecahkan masalah error SAML, periksa beberapa penyebab umum: perbedaan waktu antara IdP dan SP dapat menyebabkan timestamp assertion gagal validasi; elemen Audience harus persis cocok dengan entity ID SP yang dikonfigurasi; assertion mungkin telah melewati waktu NotOnOrAfter; atribut Destination harus cocok dengan URL Assertion Consumer Service (ACS) SP; dan SP mungkin tidak memiliki sertifikat penandatanganan IdP saat ini jika baru saja dirotasi. Parameter RelayState juga memainkan peran penting dalam alur SSO — mempertahankan URL yang awalnya diminta pengguna melalui pengalihan autentikasi, sehingga setelah autentikasi berhasil, SP dapat mengarahkan kembali ke halaman yang awalnya coba diakses pengguna.