Belajar Keycloak - Groups & Roles

#Pendahuluan

Di episode 17 kalian menyambungkan Keycloak dengan sistem eksternal lewat SCIM sehingga user ter-provisioning otomatis dari sistem HR. Episode 18 ini turun satu tingkat ke fondasi yang menentukan apa yang boleh dilakukan user: groups dan roles. Grup mengelompokkan user, peran memberi izin, dan keduanya bertemu di role mapping. Kalian akan melihat perbedaan realm roles dan client roles, cara kerja composite roles, hierarki grup, hingga pola authorization RBAC, ABAC, dan group-based permission.

#Memahami Grup di Keycloak

Grup adalah wadah user yang berbagi kesamaan, seperti divisi, lokasi, atau level akses. Grup tidak menetapkan izin secara langsung; ia menjadi titik tempel untuk menerapkan peran dan atribut ke banyak user sekaligus — jauh lebih hemat daripada mengedit user satu per satu.

#Membuat Grup

Lewat admin console, buka menu Groups lalu klik New group. Alternatif otomatis, gunakan Admin REST API:

curl -X POST "https://id.example.com/admin/realms/myrealm/groups" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "developers"}'

Endpoint manajemen grup di Admin REST API berada di bawah /admin/realms/ dengan nama realm sebagai segmen jalur. Ini penting kalian pahami jika nanti ingin membuat skrip provisioning.

#Hierarki Grup

Grup bisa memiliki subgrup. Misalnya grup engineering dengan anak developers, devops, dan qa. Hierarki ini membantu organisasi yang besar:

• Peran yang ditempelkan ke grup induk diwarisi oleh seluruh subgrup dan anggotanya.
• Keanggotaan bersifat transitif: user di devops otomatis dianggap anggota engineering.

{
  "name": "engineering",
  "subGroups": [
    {"name": "developers"},
    {"name": "devops"},
    {"name": "qa"}
  ]
}

#Group Membership

Tambahkan user ke grup lewat halaman detail grup (tab Members) atau dari profil user (tab Groups). Kuncinya: peran dan atribut grup mengalir ke semua anggota, jadi cukup kelola sekali di tingkat grup, bukan per user. Untuk melihat daftar grup dari terminal, jalankan kcadm.sh get groups -r myrealm.

#Group Attributes

Grup bisa membawa atribut key-value, misalnya department=engineering atau location=jakarta. Atribut inilah bahan bakar untuk authorization berbasis atribut (ABAC) yang akan dibahas sebentar lagi.

#Default Groups

Ada grup yang diinginkan diikuti semua user baru tanpa mereka pilih. Bukalah Realm Settings → tab Login, lalu tambahkan grup ke pengaturan Default groups. User yang baru terdaftar otomatis bergabung ke grup tersebut — pola yang umum untuk menerapkan peran onboarding sejak hari pertama.

#Memahami Roles di Keycloak

Roles (peran) adalah kumpulan izin bernama yang bisa diberikan ke user atau grup. Keycloak membedakan dua cakupan: realm dan client.

#Realm Roles vs Client Roles

Aturan praktis: simpan di realm role hal-hal yang lintas aplikasi, simpan di client role hal-hal yang spesifik aplikasi. Ini membuat role mapping tetap mudah dibaca dan tidak saling menginjak.

#Composite Roles

Composite role adalah peran yang "membungkus" peran-peran lain. Saat user diberi composite role, seluruh peran di dalamnya ikut aktif:

roles:
  - name: reader
    composite: true
    includes:
      - realm: view-user
      - realm: view-group
      - client: webapp
        role: view-basic-info

#Role Hierarchy

Composite role menciptakan semacam hierarki peran. reader lebih tinggi dari view-user karena mencakupnya. Hierarki ini berguna untuk merakit peran besar dari blok kecil, tapi hati-hati: kompleksitas naik seiring kedalaman, dan membuat audit menjadi lebih sulit.

#Role Mapping

Pemetaan peran adalah proses menempelkan role ke user atau grup:

• User level: halaman detail user → tab Role mapping.
• Group level: detail grup → tab Role mapping. Semua anggota grup otomatis mendapat peran tersebut.
• API: subjalur role-mappings/realm di bawah endpoint user realm, dan subjalur serupa di bawah endpoint grup.

Role mapping ke grup adalah teknik paling efisien untuk skala besar: tambah user ke grup, peran datang dengan sendirinya.

#Grup vs Peran: Kapan Memakai yang Mana

Garis besarnya: grup = struktur organisasi, peran = hak akses. Dalam praktik, keduanya digabung — grup diberi peran.

#Authorization: RBAC, ABAC, dan Group-Based Permissions

#RBAC (Role-Based Access Control)

Model paling umum: user atau grup diberi peran, aplikasi memeriksa peran di token (misal claim realm_access atau resource_access di JWT). Sederhana, mudah diaudit, dan menjadi basis dari hampir semua setup Keycloak.

#ABAC (Attribute-Based Access Control)

Keputusan dibuat dari atribut, bukan sekadar peran: "boleh akses jika location sama dengan negara data", "boleh jika clearance-level di atas 3". Di Keycloak, atribut ini bisa datang dari user attributes maupun group attributes.

#Group-Based Permissions

Gabungan keduanya yang paling praktis: grup memegang atribut dan peran, lalu aplikasi memutuskan berdasarkan keanggotaan grup. Ini pola yang direkomendasikan untuk onboarding dan offboarding otomatis — cukup atur keanggotaan grup.

#Fine-Grained Authorization

Untuk kontrol paling detail, Keycloak punya Authorization Services (UMA 2.0): resource, scope, policy, dan evaluasi konteks di sisi server. Ini tema besar yang akan dibahas di episode 25. Untuk episode ini, cukup tahu bahwa RBAC dan ABAC lewat grup dan peran adalah fondasi yang harus dikuasai sebelum menyentuh lapisan tersebut.

#Best Practices

#Konvensi Penamaan Peran

Gunakan pola kata kerja-benda yang konsisten, misal view-*, create-*, manage-*. Konsistensi membuat role set mudah dibaca dan aman untuk direfactor.

#Pola Desain Grup

Pilih satu basis klasifikasi: organisasi, fungsi, atau tingkat akses — jangan dicampur dalam satu hierarki. Misalnya jangan menaruh intern dan engineering sebagai sibling di level yang sama jika keduanya punya makna berbeda.

#Pemodelan Izin

Tempelkan peran ke grup, bukan ke user satu per satu. Kelola permission dari atas ke bawah: grup induk untuk hal umum, subgrup untuk pengecualian.

#Prinsip Least Privilege

Berikan hanya izin minimum yang dibutuhkan, dan periksa berkala apakah masih relevan. Kombinasikan dengan audit event di episode 22 untuk melihat siapa sebenarnya yang memakai peran tersebut.

#Penutup

Pada episode 18, kalian memetakan dua pilar authorization Keycloak: grup sebagai struktur organisasi (hierarki, membership, atribut, default groups) dan peran sebagai hak akses (realm/client, composite, role mapping), lalu menyatukannya dalam RBAC, ABAC, dan group-based permission.

Inti yang harus dibawa pulang:

• Grup untuk struktur, peran untuk izin — pisahkan keduanya agar model tetap sederhana.
• Tempelkan peran ke grup, bukan ke user perorangan, untuk skala dan kemudahan audit.
• Realm roles untuk lintas aplikasi, client roles untuk satu aplikasi — jangan mencampur keduanya sembarangan.
• Composite roles mempermudah merakit hak akses, tapi jaga kedalaman hierarki tetap dangkal.

Di episode 19 berikutnya, kalian akan mengangkat Keycloak dari sekadar kotak pasir ke instalasi nyata: installing Keycloak — ZIP/TAR standalone, container Docker dari quay.io, konfigurasi database, hingga pengaturan awal realm.