Belajar Keycloak - Fine-Grained Authorization

#Pendahuluan

Di episode 24 kalian mengamankan pintu masuk: brute force protection, security headers, dan keamanan token. Episode 25 ini bergerak lebih dalam — dari siapa yang boleh masuk menjadi apa yang boleh dilakukan setelah masuk. Autentikasi menjawab identitas; authorization menjawab otorisasi. Keycloak menyediakan modul Authorization Services untuk mengatur akses pada tingkat resource, bukan sekadar per role.

#Authorization Services di Keycloak

Authorization Services diaktifkan per klien lewat tab Authorization di halaman klien. Begitu diaktifkan, Keycloak menjadi policy decision point yang mengevaluasi setiap permintaan akses berdasarkan resource, scope, policy, dan permission yang kalian definisikan.

Pendekatan ini resource-based: keputusan dibuat per resource dengan mempertimbangkan konteks permintaan — siapa yang meminta, dari IP mana, jam berapa, dan data apa yang terlibat. Ini berbeda dari RBAC klasik yang hanya melihat label role user. Dengan context-based decisions, dua user bergolongan sama bisa mendapat keputusan berbeda karena waktu atau lokasinya berbeda.

Beberapa konsep inti yang akan kalian pakai terus:

Keycloak menerapkan UMA 2.0 sebagai fondasinya — standar yang memungkinkan pemilik resource mengatur siapa yang boleh mengakses apa, dengan alur permission ticket yang terstruktur.

#Resources & Scopes

Langkah pertama adalah memodelkan apa yang dilindungi. Di tab Authorization → Resources, kalian mendefinisikan resource dengan nama, tipe, URI, dan atribut. Scope mendeskripsikan aksi yang bisa dilakukan:

{
  "name": "Transaksi",
  "type": "urn:bank:transaction",
  "uris": ["/transactions/*"],
  "scopes": ["view", "edit", "delete"],
  "attributes": {
    "region": "jakarta"
  }
}

attributes adalah resource attributes — metadata yang bisa dipakai policy untuk keputusan berbasis konteks. Misalnya atribut region bisa menjadi dasar aturan "hanya bisa diedit dari region yang sama". uris menghubungkan resource dengan endpoint API yang dilindungi, sehingga enforcement bisa dikaitkan langsung ke rute permintaan. Scope juga bisa diatur sebagai scope permission terpisah agar penggunaannya dikendalikan per scope.

#Policies

Policy adalah logika keputusan. Keycloak menyediakan banyak tipe yang bisa dikombinasikan:

Policy role-based adalah yang paling umum: "role teller boleh view resource Transaksi". Time-based berguna untuk jam kerja: "transfer hanya boleh jam 08.00 sampai 17.00". JavaScript policy memberi fleksibilitas penuh — misalnya membandingkan atribut request dengan atribut resource secara langsung. Aggregated policy menggabungkan semuanya: role teller DAN jam kerja DAN region jakarta. Client-based berguna di skenario service-to-service, saat akses ditentukan oleh identitas aplikasi pemanggil, bukan hanya user.

#Permissions

Permission adalah pengikat antara resource (atau scope) dan satu atau lebih policy. Keycloak mengenal dua bentuk:

• Resource permission — mengatur seluruh akses ke sebuah resource.
• Scope permission — mengatur akses ke scope tertentu dalam resource.

{
  "name": "Teller boleh view transaksi",
  "type": "resource",
  "resources": ["Transaksi"],
  "scopes": ["view"],
  "policies": ["Hanya role teller", "Hanya jam kerja"]
}

Evaluasi berlangsung AND antar policy dalam satu permission: kedua policy di atas harus lulus sebelum akses diberikan. Ini bentuk paling umum dari context-based decisions — peran user benar, tetapi jam di luar jam kerja tetap ditolak.

#Alur Evaluasi Permission

Ketika aplikasi meminta akses, urutannya:

1. Authorization request — aplikasi mengirim permintaan akses yang menyebutkan resource dan scope.
2. Policy evaluation — Keycloak mengevaluasi semua policy yang terikat pada permission tersebut.
3. Permission ticket — dalam alur UMA, jika otorisasi belum jelas, diterbitkan permission ticket sebagai tanda "perlu otorisasi".
4. RPT — setelah keputusan disetujui, Keycloak menerbitkan RPT yang memuat grants.

Cara paling umum mendapatkan RPT adalah lewat token endpoint dengan UMA ticket grant:

curl -X POST "https://sso.example.com/realms/bank/protocol/openid-connect/token" \
  -H "Authorization: Bearer <access_token>" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  -d "client_id=bank-app" \
  -d "audience=bank-app" \
  --data-urlencode "permission=Transaksi#view"

Parameter permission diisi kombinasi resource dan scope yang dipisahkan tanda pagar, misalnya resource Transaksi dengan scope view. urn:ietf:params:oauth:grant-type:uma-ticket adalah grant type khusus yang menandakan "beri saya RPT untuk permission ini". Keycloak juga menyediakan endpoint authorization request (/authz/authorize) dan entitlements endpoint untuk pola lama — menarik seluruh entitlement seorang user terhadap resource server sekaligus — sementara alur modern tetap berjalan lewat token endpoint.

#Implementation: PEP & PDP

Secara arsitektur, keputusan dan penegakan dipisah:

• PEP (Policy Enforcement Point) — lapisan di aplikasi yang mencegat permintaan, meminta keputusan, dan menegakkan hasilnya. Keycloak menyediakan policy enforcer atau adapter untuk bahasa populer.
• PDP (Policy Decision Point) — Keycloak sendiri, yang mengevaluasi policy dan mengeluarkan keputusan.

Untuk melindungi API, PEP dipasang di gateway atau di dalam layanan. Di arsitektur microservices, pola yang dianjurkan: satu PDP pusat, sementara setiap service memasang PEP tipis — keputusan tetap terpusat, penegakan tersebar di banyak titik.

#Penutup

Episode 25 memperkenalkan fine-grained authorization: Authorization Services per klien dengan konsep resource, scope, policy, dan permission; policy berbasis role, group, user, klien, waktu, JavaScript, dan aggregated; serta alur evaluasi dari authorization request menuju permission ticket dan RPT. Kalian juga memahami pemisahan PEP dan PDP, plus pola penerapan untuk API dan microservices.

Inti yang harus dibawa pulang:

• Authorization Services adalah PDP terpusat — aturan hidup di Keycloak, aplikasi hanya menegakkan.
• Resource + scope + policy + permission adalah model empat serangkai yang saling mengikat.
• RPT adalah bukti otorisasi — didapat lewat token endpoint dengan UMA ticket grant.
• UMA 2.0 memberi kendali ke pemilik resource — fondasi untuk model akses yang dinamis.

Di episode 26 berikutnya, kalian belajar mengelola klien dalam jumlah besar: client registration & dynamic clients — mendaftarkan aplikasi secara otomatis lewat API, memakai initial access token, dan memilih metode autentikasi klien yang tepat.