Authorization & DCL untuk ABAP CDS — Panduan Lengkap
Di episode ini kita bahas cara mengamankan hasil CDS menggunakan Data Control Language (DCL), integrasinya dengan PFCG / role-based conditions, bagaimana menggunakan annotation @AccessControl.authorizationCheck, contoh implementasi, serta langkah pengujian. Tujuannya: memastikan user hanya melihat data yang mereka berhak akses.
Ringkasan konsep
- CDS sendiri tidak otomatis memfilter baris — untuk row-level security kita pakai DCL (define role & grant rule) bersama annotation
@AccessControl.authorizationCheck: #CHECKpada CDS. - DCL didefinisikan di file access control (.dcl) dan berisi role yang melakukan
grant select on <cds>dengan kondisi. - Untuk integrasi dengan PFCG (role-based conditions), DCL mendukung pemetaan kondisi yang diisi lewat PFCG sehingga admin Basis/Security bisa mengelola nilai kondisi per role/user. :contentReference[oaicite:0]{index=0}
1) Annotation di CDS — aktifkan pemeriksaan DCL
Untuk mengaktifkan DCL pada sebuah CDS view, tambahkan annotation berikut di definisi CDS:
@AccessControl.authorizationCheck: #CHECK
define view ZCDS_SALES_CONS
as select from ...
{ ... }
Dengan #CHECK sistem akan menerapkan aturan DCL (jika ada) saat CDS diakses baik lewat ABAP Open SQL, OData, maupun Data Preview (tergantung context). Jika annotation tidak ada, nilai default biasanya #NOT_REQUIRED. :contentReference[oaicite:1]{index=1}
2) Struktur DCL — konsep & contoh (pattern)
DCL berisi definisi role dan aturan grant. Berikut contoh pola umum (template) yang sering dipakai — sesuaikan nama object dan field dengan sistem Anda:
-- File: ZDCL_SALES.dcl
define role ZDCL_SALES {
grant select on ZCDS_SALES_CONS
where sales_org = $session.user_sales_org; -- contoh placeholder
}
Catatan: variabel $session.* pada contoh di atas adalah ilustrasi. Dalam praktik yang umum, Anda dapat menggunakan pfcg_condition atau inheritance untuk memetakan kondisi dari PFCG ke DCL (lihat contoh berikut). Untuk sintaks dan opsi lengkap, rujuk dokumentasi SAP. :contentReference[oaicite:2]{index=2}
3) Contoh DCL menggunakan PFCG condition (pattern aman untuk production)
Cara populer: simpan daftar perusahaan / org unit di kondisi PFCG (role) lalu DCL memanggil kondisi itu — sehingga admin cukup assign role di PFCG tanpa ubah DCL. Contoh pattern (template):
-- File: ZDCL_SALES.dcl
define role ZDCL_SALES {
grant select on ZCDS_SALES_CONS
where company in pfcg_condition( 'ZCOND_COMPANY' ); -- ambil nilai dari PFCG condition 'ZCOND_COMPANY'
}
Dengan pendekatan ini, security admin membuat condition ZCOND_COMPANY di PFCG dan menetapkan nilai perusahaan (contoh: 1000,2000) ke role; DCL akan menggunakan nilai tersebut untuk memfilter baris. Ini memisahkan concern developer (kode) dan admin (data akses). :contentReference[oaicite:3]{index=3}
4) Contoh lengkap alur implementasi (step-by-step)
- Buat/ubah CDS Consumption View dan tambahkan annotation:
@AccessControl.authorizationCheck: #CHECK. - Buat DCL file (ABAP: New → Core Data Services → Access Control). Di dalamnya definisikan role dan aturan grant sebagaimana contoh di atas.
- Jika pakai PFCG conditions: buat condition di PFCG (Transaction PFCG → Role → Tab: Menu/Authorization → Conditions / Parameterization; admin mengisi nilai kondisi seperti daftar company codes atau plant).
- Transport & Activate: activate CDS & DCL (Ctrl+F3). Pastikan DCL ter-transport ke target system sesuai landscape.
- Assign PFCG role ke user atau ke group yang relevan.
- Test: login sebagai user A (yang punya company X) → query CDS (data preview / OData / ABAP SELECT) → hanya lihat baris company X. Login sebagai user B → lihat baris company Y. Lakukan juga test tanpa role untuk pastikan akses terblokir. :contentReference[oaicite:4]{index=4}
5) Testing & verifikasi
- Data Preview di ADT: untuk DCL yang menggunakan PFCG, Data Preview di Eclipse tidak selalu menampilkan hasil sesuai user lain — gunakan user di system (atau debug session) untuk memverifikasi behavior sebenarnya.
- ABAP SELECT: panggil CDS dari ABAP sebagai user target dan lihat apakah hasil terfilter sesuai DCL.
- OData / Fiori: akses endpoint OData sebagai user target; cek /$metadata dan query collection (gunakan Postman atau browser) untuk memastikan row-level filtering jalan.
- SU53 & ST01: jika akses gagal, gunakan SU53 untuk cek missing authorization/failed checks; gunakan trace jika perlu.
6) Advanced: inheritance & role composition
DCL mendukung inheritance dan komposisi role — mis. Anda dapat INHERIT kondisi dari role lain, atau membuat role yang mewarisi kondisi entitas lain sehingga mempermudah reuse aturan keamanan. Ini berguna ketika organisasi punya struktur role yang kompleks. Untuk detail syntax advanced lihat dokumentasi DCL (DEFINE ROLE variants). :contentReference[oaicite:5]{index=5}
7) Best practices & checklist
- Gunakan @AccessControl.authorizationCheck: #CHECK pada CDS yang berisi data sensitif — jangan andalkan UI saja.
- Pisahkan developer & admin tasks: definisi DCL di repo git/transport, nilai kondisi di-manage oleh admin (PFCG).
- Dokumentasikan tiap rule: tujuan, fields yang dipakai, mapping ke PFCG condition.
- Minimal privilege: buat rule seketat perlu (least privilege).
- Uji di environment non-prod dengan user-role berbeda sebelum deploy ke production.
- Perhatikan performance: kondisi kompleks di DCL dapat mempengaruhi runtime; optimalkan field index & pushdown di HANA jika perlu.
DCL adalah mekanisme standar untuk row-level security pada CDS. Gunakan
@AccessControl.authorizationCheck: #CHECK pada CDS, definisikan role & grant di file DCL, dan bila perlu gunakan integrasi pfcg_condition agar admin bisa mengelola nilai kondisi lewat PFCG. Selalu test behavior dengan user nyata dan dokumentasikan aturan secara jelas.
➡️ Next (Episode 11): Performance & Best Practice untuk CDS — tips indexing, filter pushdown, menghindari pitfall, dan tools monitoring (ST05, SQL Monitor).
