Belajar Backstage - Authorization: Permission Framework & RBAC

#Pendahuluan

Di episode 12, kalian merapikan lapisan penyimpanan: database, cache, dan search index. Data yang tersimpan itu kini perlu dijaga — siapa yang boleh melihat entity catalog, siapa yang boleh menjalankan template, siapa yang boleh melakukan aksi tertentu. Episode 13 ini membahas authorization: permission framework bawaan Backstage dan cara membangun kontrol akses berbasis peran dengan RBAC Backend Plugin. Kalian ingat authentication di episode 8 — episode ini adalah pasangannya: authentication memverifikasi siapa kalian, authorization menentukan apa yang boleh kalian lakukan.

#Konsep Dasar Permissions

Backstage memodelkan authorization lewat permissions. Sebuah permission adalah pernyataan tentang suatu aksi, misalnya "melihat entity", "menjalankan template", atau "menghapus entity". Setiap kali pengguna mencoba melakukan aksi yang dilindungi, Backstage mengajukan pertanyaan: apakah principal ini diizinkan melakukan aksi ini?

Ada dua jenis permission:

• Basic permission — keputusan biner: diizinkan atau ditolak. Contohnya permission untuk mengatur plugin admin.
• Resource-based permission — keputusan bisa bergantung pada kondisi tentang resource tertentu, misalnya hanya entity milik tim kalian sendiri.

#Conditions dan Rules

Conditions memungkinkan keputusan dibuat bukan hanya dari siapa penggunanya, tetapi juga dari sifat resource yang dituju. Backstage menyediakan aturan (rules) bawaan seperti isEntityOwner atau hasEntityMetadata, yang bisa digabungkan dengan logika AND dan OR untuk membentuk kondisi yang kompleks.

Contoh pola umum: platform team boleh melihat semua entity, sementara developer biasa hanya boleh melihat entity yang mereka miliki atau yang menandai mereka sebagai member. Kondisi inilah yang membuat permission tidak sekadar on/off, melainkan berkonteks pada resource.

#Permission Policies: createPermissionPolicy

Keputusan akhir ada di permission policy. Backend permission mengirimkan request check ke policy, dan policy menjawab allow atau deny. Cara modern untuk menulis policy adalah createPermissionPolicy, yang diimpor dari package permission backend:

import { createPermissionPolicy } from '@backstage/plugin-permission-backend';
 
const examplePolicy = createPermissionPolicy({
  async handle(request, user) {
    if (request.permission.name === 'catalog.entity.read') {
      return { result: AuthorizationResult.ALLOW };
    }
    return { result: AuthorizationResult.DENY };
  },
});

Policy di atas sederhana: izinkan semua pembacaan entity, tolak yang lain. Dalam praktik, policy akan mengombinasikan identitas user, kondisi resource, dan kebijakan organisasi. Policy ditulis sebagai handler async biasa di atas @backstage/backend-defaults, sehingga keputusan bisa di-log dan di-debug layaknya kode backend lainnya.

#Mendaftarkan Policy dan Menguji Alur

Policy tidak berlaku otomatis — ia harus didaftarkan ke permission backend saat backend diinisialisasi. Setelah didaftarkan dan service di-restart, setiap permission check yang masuk akan melewati policy tersebut. Kalian bisa langsung menguji dari UI: coba akses sebuah halaman sebagai user biasa, lalu bandingkan perilakunya saat memakai akun admin.

yarn dev

Saat mengembangkan, ada baiknya menuliskan kasus uji kecil untuk tiap permission: siapa yang boleh, siapa yang tidak boleh, dan apa yang terjadi saat resource-nya berubah. Ini mencegah regresi di kemudian hari — terutama setelah RBAC dari bagian berikut ikut terhubung ke policy yang sama.

#Perbandingan Konsep Authorization

Alur lengkapnya: plugin mengajukan permission check, backend permission meneruskan ke policy, policy memutuskan dengan mempertimbangkan kondisi, lalu hasilnya dikembalikan ke plugin. Semua ini berjalan transparan di dalam request yang sama.

#RBAC Backend Plugin

Menulis policy manual untuk setiap kombinasi peran itu melelahkan. Untuk kontrol akses berbasis peran yang bisa dikelola secara dinamis, Backstage punya RBAC Backend Plugin — plugin komunitas yang mengelola roles dan policies lewat data, bukan kode.

RBAC backend menyimpan roles dan policies yang ditautkan ke role. Satu role bisa diberi beberapa permission, dan permission bisa berupa allow atau deny:

roles:
  - name: user/default/platform-engineer
    permissions:
      - policyEntity: 'entity'
        permission: 'catalog-entity-read'
        effect: 'allow'
        conditions:
          rule: 'IS_ENTITY_KIND'
          params:
            kinds: ['Component']

Dengan pola ini, menambah role baru atau mengubah hak akses cukup lewat data — tanpa menulis ulang kode policy. Permission yang sama yang didefinisikan di permission framework tetap berlaku; RBAC hanya mengikatnya ke role.

#Role Assignment dan UI Admin

Setelah role terdefinisi, langkah berikutnya adalah role assignment — menautkan user atau group ke role. Assignment bisa dilakukan lewat catalog: karena user dan group di Backstage berasal dari catalog (dan sering diimpor dari identity provider), role cukup menyebut group seperti group/default/platform-eng.

RBAC Backend Plugin juga menyediakan UI admin di frontend. Dengan UI ini, admin bisa melihat daftar role, mengedit permissions yang menempel, dan melihat siapa saja yang masuk dalam setiap role — tanpa menyentuh kode atau restart backend.

#Integrasi dengan Identity Provider

Kekuatan RBAC Backstage muncul saat dihubungkan dengan identity provider yang sudah kalian punya. Karena user dan group diimpor ke catalog dari provider (misalnya Microsoft Entra ID, GitHub organization, atau LDAP), struktur tim yang sudah ada langsung menjadi dasar penentuan role.

Alurnya: identity provider menyuplai user dan group, catalog mereplikasinya sebagai entity, RBAC menautkan role ke group, lalu permission check memutuskan akses berdasarkan keanggotaan group. Ini membuat model akses mengikuti organisasi yang sebenarnya, bukan duplikasi manual yang mudah usang.

Penting juga untuk menetapkan siapa yang bisa mengelola RBAC itu sendiri — biasanya role admin khusus yang hanya dipegang segelintir orang. Sistem authorization yang sehat selalu punya jalur audit: siapa mengubah role, kapan, dan efek apa yang ditimbulkan perubahan itu terhadap akses pengguna.

#Penutup

Episode 13 ini membawa kalian ke jantung authorization Backstage: permission sebagai pernyataan aksi, condition untuk keputusan berkonteks, permission policy sebagai pengambil keputusan akhir, serta RBAC Backend Plugin untuk mengelola role dan assignment secara dinamis lewat UI. Ini menutup lubang keamanan yang tersisa setelah authentication di episode 8.

Inti yang harus dibawa pulang:

• Authorization terpisah dari authentication — memverifikasi identitas tidak berarti memberi semua akses.
• Gunakan resource-based permission untuk keputusan yang berkonteks pada entity.
• RBAC mengelola akses lewat data — role dan policy bisa diubah dari UI tanpa deploy ulang.
• Grup dari identity provider adalah fondasi role — manfaatkan struktur organisasi yang sudah ada.

Di episode 14 berikutnya, kalian berintegrasi dengan dunia luar: secrets & external service integration — bagaimana Backstage meneruskan request ke layanan eksternal lewat proxy backend dan menjaga token tetap aman sepanjang siklus hidupnya.