SSO untuk aplikasi internal: petakan klaim SAML/OIDC ke peran dan tim

Mengapa pemetaan klaim penting untuk aplikasi internal

Single sign-on terdengar sederhana: klik "Sign in with Okta" atau "Sign in with Azure AD" dan Anda masuk. Bagian yang sulit adalah apa yang terjadi setelah itu. Tanpa pemetaan klaim yang jelas, orang berakhir dengan akses berlebih (seorang agen support melihat payroll) atau akses terlalu sedikit (karyawan baru tidak bisa membuka alat yang mereka butuhkan di hari pertama).

Aplikasi internal lebih rumit daripada aplikasi publik karena dibagikan antar tim dan berubah terus. Satu alat bisa dipakai Support, Finance, dan Sales secara bersamaan. Struktur organisasi bergeser, kontraktor datang dan pergi, dan tim diganti nama atau dibagi. Jika aturan akses hanya hidup di kepala orang, SSO akan dengan setia menyalin kekacauan itu ke aplikasi Anda.

Pemetaan klaim adalah cara Anda mengubah data identitas dari identity provider (IdP), seperti grup, departemen, atau jabatan, menjadi izin yang dipahami aplikasi Anda. Biasanya ini berarti menentukan:

• Peran apa saja yang ada di aplikasi (admin, manager, viewer, dll.)
• Tim atau workspace mana yang dimiliki pengguna
• Apa yang setiap peran bisa lakukan, dan apa yang setiap tim bisa lihat
• Siapa yang mendapat akses otomatis dan siapa yang perlu persetujuan

Dua risiko yang paling sering menimbulkan masalah:

• Pemetaan yang salah. Nama grup cocok ke peran yang keliru, atau grup umum "All Employees" secara tidak sengaja memberi hak admin.
• Klaim yang hilang. IdP tidak mengirim grup untuk beberapa pengguna, sebuah atribut kosong, atau token terlalu besar sehingga terpotong.

Aplikasi Anda butuh default yang aman sehingga data yang hilang atau tak terduga tidak berubah menjadi akses tidak sengaja.

SAML vs OIDC klaim secara sederhana

Saat Anda masuk dengan SSO, IdP mengirimkan paket kecil fakta tentang Anda. Setiap fakta adalah klaim, pada dasarnya field berlabel seperti "email = [email protected]" atau "department = Finance".

SAML dan OIDC bisa membawa fakta serupa, tapi mereka mengemasnya berbeda.

SAML umum di setup enterprise yang lebih tua. Biasanya mengirim dokumen XML (assertion) dengan atribut. Atribut-atribut itu adalah klaim yang dibaca aplikasi Anda.

OIDC lebih baru dan dibangun di atas OAuth 2.0. Biasanya mengirim token JSON yang ditandatangani (ID token) plus user info opsional, di mana field di dalam token adalah klaim.

Untuk aplikasi internal, Anda biasanya peduli pada beberapa klaim kecil:

• Alamat email
• ID pengguna stabil dari IdP (subject)
• Nama lengkap (atau nama depan dan belakang)
• Keanggotaan grup (tim, security groups)
• Departemen atau jabatan

Satu perbedaan mencegah banyak kebingungan:

Autentikasi menjawab "siapa pengguna ini?" Klaim seperti ID pengguna yang stabil dan email membantu Anda menautkan login SSO ke akun yang benar.

Otorisasi menjawab "apa yang boleh mereka lakukan?" Klaim seperti grup atau departemen membantu Anda memetakan pengguna ke peran dan tim di dalam aplikasi.

Dua orang bisa autentikasi dengan sukses, tetapi hanya orang dengan klaim grup "Finance" yang harus diizinkan ke layar billing.

Peran dan tim: tentukan apa yang akan Anda petakan

Sebelum Anda memetakan atribut SAML atau mengonversi klaim OIDC menjadi izin, pastikan dua hal berbeda yang perlu diketahui aplikasi Anda:

• Peran mendefinisikan apa yang bisa dilakukan seseorang (izin).
• Tim mendefinisikan di mana mereka berada (ruang lingkup).

Peran menjawab pertanyaan seperti: apakah orang ini bisa melihat, mengedit, menyetujui, mengekspor, mengelola pengguna, atau mengubah pengaturan?

Tim menjawab pertanyaan seperti: departemen, wilayah, antrean, atau cost center mana orang ini bekerja, dan catatan mana yang harus mereka lihat?

Jaga peran tetap sedikit dan stabil. Kebanyakan aplikasi internal hanya butuh beberapa peran yang jarang berubah, walau orang berpindah-pindah. Tim harus mencerminkan realitas sehari-hari: Support Tier 2, cakupan EMEA, pemilik antrean sementara.

Prinsip least privilege adalah default paling aman. Banyak aplikasi internal cukup dengan tiga peran:

• Viewer: bisa membaca data dan mencari
• Editor: bisa membuat dan memperbarui catatan
• Admin: bisa mengelola pengaturan, pengguna, dan aturan akses

Tuliskan, dalam bahasa sederhana, apa yang tiap peran izinkan. Ini mencegah "admin mengejutkan" saat nama grup berubah dan memudahkan review nanti.

Akses berbasis grup: cara memikirkan grup IdP

Akses berbasis grup berarti aplikasi Anda tidak memutuskan izin orang per orang. Sebagai gantinya, aplikasi mengandalkan IdP untuk menjaga keanggotaan grup, dan aplikasi Anda memetakan grup-grup itu ke peran dan tim.

Mulailah dengan menentukan apa yang diberikan sebuah grup. Di banyak alat, satu grup dipetakan ke satu peran (mis. "Support Agent") dan opsional satu tim (mis. "Tier 2"). Kuncinya adalah pemetaan tetap membosankan dan dapat diprediksi: grup yang sama selalu berarti akses yang sama.

Saat pengguna ada di banyak grup

Orang sering menjadi anggota lebih dari satu grup IdP. Anda butuh aturan untuk menyelesaikannya, dan harus menjaga agar aturan itu stabil.

Pendekatan umum:

• Aturan aditif: gabungkan izin dari semua grup yang cocok (cocok saat izin dibatasi ketat)
• Aturan prioritas: pilih grup prioritas tertinggi dan abaikan sisanya (berguna saat peran konflik)
• Hybrid: aditif untuk tim, prioritas untuk peran

Apa pun yang Anda pilih, dokumentasikan. Mengubah ini nanti bisa membuat pengguna tiba-tiba mendapat atau kehilangan akses.

Gunakan konvensi penamaan yang bisa diskalakan

Nama grup yang jelas mengurangi kesalahan dan mempermudah audit. Pola praktis:

• --

Contoh: support-tool-prod-agent atau finance-tool-staging-viewer. Ini membantu menghindari penggunaan ulang nama samar seperti "Admins" di banyak aplikasi.

Jika pengguna tidak termasuk grup relevan, default ke tanpa akses (atau status tamu yang sangat terbatas) dan tunjukkan pesan yang menjelaskan cara meminta akses.

Penautan akun: mencocokkan pengguna SSO ke akun aplikasi

SSO membuktikan siapa seseorang, tapi aplikasi Anda masih harus memutuskan akun mana yang dihubungkan ke identitas itu. Tanpa penautan akun, orang yang sama bisa berakhir dengan beberapa akun seiring waktu karena identifier berubah: email baru, perubahan nama, pindah antar anak perusahaan, mengganti IdP.

Pilih satu kunci yang stabil dan unik sebagai kecocokan utama.

• Untuk OIDC, biasanya klaim sub dari IdP.
• Untuk SAML, seringkali NameID persisten atau atribut user ID tak berubah.

Simpan nilai itu sebagai "IdP user ID" bersama issuer/entity ID IdP, sehingga sub yang sama dari IdP berbeda tidak bisa bertabrakan.

Email berguna, tapi perlakukan sebagai kunci kenyamanan, bukan sumber kebenaran. Orang mengganti email karena rename, migrasi domain, atau merger. Alias dan inbox bersama juga bisa menciptakan kecocokan mengejutkan. Jika mencocokkan berdasarkan email, lakukan hanya saat sinyal IdP terverifikasi, dan pertimbangkan langkah konfirmasi satu kali.

Saat login pertama, kebanyakan alat internal memilih satu pola onboarding:

• Auto-create: buat akun segera dan beri akses minimal.
• Invite-only: hanya izinkan login untuk pengguna yang sudah dibuat sebelumnya (atau sudah disetujui) di aplikasi.
• Alur persetujuan: buat akun, tapi blok akses sampai manager atau admin menyetujui peran/tim.

Default aman adalah auto-create dengan tidak ada izin default, lalu beri akses berdasarkan grup atau langkah persetujuan.

Langkah demi langkah: memetakan klaim ke peran dan tim

Pemetaan klaim yang baik membuat SSO terasa tak terlihat: orang masuk dan langsung berada di tempat yang tepat dengan akses yang sesuai.

Mulailah dengan menuliskan model akses Anda dalam bahasa sederhana. Daftar setiap peran (Viewer, Agent, Manager, Admin) dan setiap tim (Support, Finance, IT), plus siapa yang harus mendapatkannya dan mengapa.

Kemudian konfirmasi apa yang IdP bisa kirim. Untuk SAML atau OIDC, biasanya Anda ingin ID pengguna yang stabil (subject atau NameID), email, dan satu atau lebih atribut grup. Tangkap nilai grup persis seperti tampil, termasuk huruf besar/kecil dan prefix. "Support" dan "support" tidak sama.

Alur praktis:

• Definisikan peran dan tim, dan tetapkan pemilik untuk masing-masing (orang yang dapat menyetujui perubahan).
• Daftar klaim yang tersedia dan nama grup persis dari IdP, termasuk kasus tepi (kontraktor, inbox bersama).
• Tulis aturan pemetaan: grup-ke-peran, grup-ke-tim, dan urutan override saat banyak grup cocok.
• Uji dengan 3–5 tipe pengguna nyata (karyawan baru, manager, kontraktor, admin) menggunakan akun IdP nyata.
• Untuk tiap pengguna uji, tulis hasil peran/tim yang diharapkan terlebih dahulu, lalu masuk dan bandingkan.

Simpan satu contoh kecil agar aturan konkret. Jika pengguna berada di "okta-support", mereka menjadi tim Support plus peran Agent. Jika mereka juga di "okta-support-managers", peran Manager menimpa Agent.

Terakhir, tambahkan cara debugging sederhana. Log klaim mentah yang diterima (dengan aman), aturan yang cocok, dan hasil peran/tim akhir. Ketika seseorang berkata, "Saya masuk, tetapi tidak bisa melihat tool saya," ini mengubah tebakan menjadi pemeriksaan cepat.

Default aman saat klaim hilang

Klaim yang hilang itu normal. IdP mungkin tidak mengirim grup untuk service account, sebuah konektor mungkin menghilangkan field, atau pengguna sedang migrasi. Perlakukan "tidak ada data" sebagai "tidak dipercaya."

Default paling aman adalah deny-by-default: tidak ada peran, tidak ada tim, tidak ada akses. Jika harus mengizinkan masuk agar seseorang bisa meminta akses, buat itu read-only dan jelas terbatas.

Pilih satu perilaku dan dokumentasikan:

• Blokir login dengan pesan jelas: "Akun Anda tidak memiliki akses yang ditetapkan. Hubungi support."
• Izinkan akses terbatas dengan peringatan dan nonaktifkan aksi sensitif.
• Buat record pengguna tapi beri peran atau tim nol sampai disetujui.

Jangan pernah default ke admin, bahkan sementara.

Rencanakan untuk data parsial. Jika Anda mendapatkan email tetapi tidak ada grup, Anda masih bisa membuat akun dan mengarahkannya ke persetujuan. Jika Anda mendapatkan grup tetapi tidak ada identifier stabil, hindari auto-linking ke akun yang ada karena itu bisa melampirkan identitas orang yang salah.

Miliki jalur eskalasi untuk kegagalan:

• Pemilik bernama (IT atau admin aplikasi) yang bisa menyetujui akses
• Alur penetapan peran manual dengan catatan audit
• Cara untuk memeriksa ulang klaim pada login berikutnya
• Tenggat waktu untuk akun "pending access"

Menangani perubahan, penghapusan, dan offboarding

Orang berpindah tim, ganti manager, dan keluar perusahaan. Setup SSO Anda harus memperlakukan ini sebagai hal normal.

Saat seseorang pindah tim, perbarui akses pada login berikutnya: evaluasi ulang klaim grup dan terapkan pemetaan saat ini. Hindari akses yang "lengket" yang tetap selamanya karena pernah diberikan.

Mereka yang keluar berbeda. Menunggu login berikutnya tidak cukup. Anda ingin akses mereka berakhir cepat, walau masih memiliki sesi aktif. Itu biasanya berarti menonaktifkan akun di IdP, dan aplikasi Anda harus memperlakukan identitas yang dinonaktifkan atau hilang sebagai diblokir segera.

Deprovisioning harus dapat diprediksi: nonaktifkan pengguna, hapus keanggotaan tim, dan simpan data audit. Seringkali Anda perlu mempertahankan catatan seperti persetujuan, komentar, dan riwayat untuk kepatuhan, sambil memblokir aksi baru.

Kontraktor dan akses sementara perlu perhatian ekstra. Masukkan mereka ke grup berbatas waktu di IdP, atau lampirkan tanggal review pada peran mereka agar akses tidak tersisa setelah proyek selesai.

Kebijakan offboarding praktis:

• Periksa klaim pada setiap login dan segarkan keanggotaan tim dari IdP
• Saat pengguna dihapus dari grup yang diperlukan, turunkan hak segera (login berikutnya atau sinkron berikutnya)
• Nonaktifkan akun sambil mempertahankan jejak audit dan histori kepemilikan
• Mewajibkan tanggal akhir untuk akses kontraktor dan tinjau sebelum perpanjangan
• Jalankan review akses berkala untuk peran sensitif seperti finance atau admin

Kesalahan umum dan jebakan yang harus dihindari

Kebanyakan outage SSO bukan disebabkan SAML atau OIDC yang "sulit." Mereka terjadi karena aplikasi membuat asumsi tidak aman tentang orang, grup, dan identifier.

Kesalahan umum adalah mencampur pemetaan peran dengan pemetaan tim. Peran adalah "apa yang bisa Anda lakukan?" Tim adalah "di mana Anda berada?" Jika Anda memetakan grup tim langsung ke peran kuat seperti Admin, seringkali Anda memberi akses luas pada siapa pun yang kebetulan berada di tim itu.

Jebakan lain adalah mengandalkan email sebagai satu-satunya identifier untuk penautan akun. Email berubah, dan alias bisa membuat duplikat. Lebih baik pakai IdP user ID yang stabil (seperti subject/NameID) sebagai kunci utama dan traktasikan email sebagai field tampilan dan notifikasi.

Masalah lain yang sering terjadi:

• Membuka akses saat grup hilang (harusnya default ke tanpa akses atau akses rendah, bukan akses penuh)
• Nama grup yang tidak jelas dan dipakai ulang antara dev, staging, dan production
• Menganggap keanggotaan grup sebagai daftar izin tanpa meninjau apa arti tiap grup
• Tidak menangani pengguna multi-tim yang butuh akses ke lebih dari satu area tanpa menjadi admin
• Melupakan partner dan kontraktor yang seharusnya terisolasi dari tim karyawan

Uji kasus tepi sebelum diluncurkan. Seorang analis finance di incident response mungkin butuh dua tim dan satu peran ditinggikan. Jika aturan Anda hanya mengizinkan satu tim, mereka akan kehilangan akses atau mendapatkan izin berlebih.

Daftar periksa cepat sebelum go live

Sebelum Anda mengaktifkan SSO untuk semua orang, lakukan dry run dengan beberapa akun uji dari tiap tim. Kebanyakan masalah akses muncul segera saat Anda menguji karyawan baru, perubahan peran, dan kasus offboarding.

Mulai dengan penautan akun. Pilih satu identifier unik yang tidak berubah seiring waktu, dan patuhi itu. Di OIDC biasanya sub. Di SAML sering NameID atau atribut immutable khusus.

Selanjutnya, tentukan apa yang terjadi saat klaim hilang. Default paling aman adalah tidak ada akses elevated (dan di banyak aplikasi, tidak ada akses) saat klaim grup atau peran kosong. Pastikan Anda punya setidaknya satu peran ber-privilege rendah yang mengizinkan orang masuk tanpa mengekspos aksi sensitif, jika itu cocok dengan alur kerja Anda.

Daftar pemeriksaan pra-peluncuran sederhana:

• Konfirmasi identifier linking Anda stabil dan unik (dan Anda bisa melihatnya di log)
• Verifikasi klaim grup yang hilang tidak memberi akses lebih dari peran rendah
• Wajibkan akses admin cocok dengan grup admin eksplisit, plus langkah persetujuan kedua (meskipun manual)
• Uji penghapusan: saat pengguna keluar dari grup, akses turun pada login berikutnya (atau sinkron berikutnya)
• Tuliskan aturan pemetaan agar rekan bisa memahaminya pada satu halaman

Contoh: alat internal untuk support dan finance dengan grup SSO

Bayangkan sebuah alat operasi yang dipakai harian oleh Support, Finance, dan beberapa manager. Anda ingin orang sign in dan langsung mendapatkan layar dan aksi yang tepat tanpa admin memperbaiki akun secara manual.

Buat beberapa grup IdP dan petakan ke peran dan tim di aplikasi:

• ops-support -> Role: Support Agent, Team: Support
• ops-finance -> Role: Finance Analyst, Team: Finance
• ops-managers -> Role: Manager, Team: Management

Begini jalannya.

Sekarang kasus perubahan email: Omar berubah dari [email protected] ke [email protected]. Karena aplikasi menautkan akun menggunakan IdP user ID yang stabil (mis. sub untuk OIDC, atau NameID persisten untuk SAML) bukannya email, dia tidak mendapat akun duplikat. Dia mempertahankan histori dan jejak audit yang sama.

Untuk memverifikasi akses tanpa menebak-nebak, simpan tampilan "effective access" yang menunjukkan identitas IdP yang ditautkan, grup yang diterima, peran yang dihasilkan, dan tim. Saat sesuatu terlihat salah, Anda bisa cepat tahu apakah itu masalah IdP, aturan pemetaan, atau klaim yang hilang.

Langkah selanjutnya: jaga akses tetap dapat diprediksi saat organisasi berubah

Bagian tersulit bukan peluncuran pertama. Melainkan menjaga akses tetap masuk akal setelah reorganisasi, tim baru, dan pengecualian sementara.

Simpan dokumen pemetaan satu halaman yang menjawab:

• Grup IdP mana memetakan ke peran dan tim aplikasi mana
• Apa defaultnya saat klaim hilang (dan siapa yang menyetujui perubahan)
• Siapa pemilik tiap peran berisiko tinggi (finance admin, user admin, data export)
• Bagaimana kontraktor dan service account ditangani
• Di mana sumber kebenaran berada (IdP vs aplikasi)

Mulai dengan pilot kecil di satu departemen yang batasnya jelas, perbaiki kasus tepi, lalu perluas tanpa menciptakan aturan baru. Tetapkan review berkala untuk akses yang dapat menyebabkan kerusakan nyata: bulanan untuk peran admin dan berisiko tinggi, kuartalan untuk peran normal.

Jika Anda membangun aplikasi internal sendiri, akan lebih mudah jika peran, tim, dan logika bisnis berada dekat sehingga perubahan mudah diuji. AppMaster (appmaster.io) adalah salah satu opsi bagi tim yang ingin memodelkan peran dan alur kerja secara visual dan menghasilkan kode backend, web, dan mobile nyata saat kebutuhan berubah, tanpa menumpuk perbaikan izin yang sekali pakai.