CDS Access Control ermöglicht die Definition von Berechtigungsprüfungen direkt auf CDS View-Ebene. Mit der Data Control Language (DCL) werden Zugriffsregeln deklarativ definiert, die automatisch bei jedem Zugriff auf den View angewendet werden.
Grundkonzept
Access Control in CDS verlagert die Berechtigungsprüfung von der Anwendungslogik in die Datenbank-Schicht:
| Klassische Prüfung | CDS Access Control |
|---|---|
AUTHORITY-CHECK im Code | DCL-Definition am View |
| Manuell bei jedem Zugriff | Automatisch bei SELECT |
| Leicht zu vergessen | Immer aktiv |
| Imperativer Code | Deklarative Regeln |
| Schwer zu warten | Zentral definiert |
Vorteile
- Zentrale Definition: Berechtigung einmal definiert, überall wirksam
- Keine Vergesslichkeit: Zugriff ohne Berechtigung unmöglich
- Performance: Optimierung durch DB-Pushdown
- Transparenz: Regeln direkt am View sichtbar
Access Control Definition
Eine Access Control Definition ist ein separates CDS-Artefakt mit der Endung .dcl:
@EndUserText.label: 'Access Control für Bestellungen'@MappingRole: truedefine role ZI_Order { grant select on ZI_Order where ( CompanyCode ) = aspect pfcg_auth( Z_BUKRS, BUKRS, ACTVT = '03' );}Struktur einer DCL
| Element | Beschreibung |
|---|---|
define role | Definiert eine Zugriffsrolle |
grant select on | Gewährt Lesezugriff auf den View |
where | Bedingung für Datenzugriff |
aspect | Berechtigungsaspekt (z.B. PFCG) |
PFCG-Autorisierung
Der häufigste Anwendungsfall ist die Integration mit PFCG-Berechtigungsobjekten:
@EndUserText.label: 'Sales Order Access'@MappingRole: truedefine role ZI_SalesOrder { grant select on ZI_SalesOrder where ( SalesOrganization ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );}Parameter des pfcg_auth Aspects
aspect pfcg_auth( <Berechtigungsobjekt>, <Feld im Objekt>, <Aktivität> = '<Wert>')- Berechtigungsobjekt: Name des PFCG-Objekts (z.B.
V_VBAK_VKO) - Feld im Objekt: Zu prüfendes Feld (z.B.
VKORG) - Aktivität: ACTVT-Wert (
01=Anlegen,02=Ändern,03=Anzeigen)
Mehrere Felder prüfen
@MappingRole: truedefine role ZI_Material { grant select on ZI_Material where ( Plant, MaterialType ) = aspect pfcg_auth( M_MATE_WRK, WERKS, MTART, ACTVT = '03' );}Komplexe Bedingungen
AND-Verknüpfung
define role ZI_PurchaseOrder { grant select on ZI_PurchaseOrder where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' ) and ( PurchasingOrganization ) = aspect pfcg_auth( M_BEST_EKO, EKORG, ACTVT = '03' );}OR-Verknüpfung
define role ZI_Document { grant select on ZI_Document where ( DocumentType ) = aspect pfcg_auth( Z_DOCTYPE, BSART, ACTVT = '03' ) or ( DocumentType ) = 'PUBLIC';}Kombinierte Logik
define role ZI_Order { grant select on ZI_Order where ( ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' ) and ( ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' ) or Status = 'RELEASED' ) );}Pfad-Ausdrücke für Assoziationen
Bei hierarchischen Daten kann die Berechtigung über Assoziationen geprüft werden:
@AccessControl.authorizationCheck: #CHECKdefine view entity ZI_OrderItem as select from zorder_item association [1..1] to ZI_Order as _Order on $projection.OrderID = _Order.OrderID{ key OrderID, key ItemNumber, Material, Quantity, _Order}Die DCL prüft über den Pfad:
define role ZI_OrderItem { grant select on ZI_OrderItem where ( _Order.CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );}Tiefe Pfade
define role ZI_OrderItemSchedule { grant select on ZI_OrderItemSchedule where ( _OrderItem._Order.CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );}Aspekt-basierte Berechtigungen
Eigene Berechtigungsaspekte
Neben pfcg_auth können eigene Aspekte definiert werden:
@EndUserText.label: 'User Country Aspect'define abstract entity ZA_UserCountry{ Country : land1;}Verwendung in DCL:
define role ZI_Customer { grant select on ZI_Customer where Country = aspect ZA_UserCountry.Country;}Inherit Aspect
Der inherit Aspect übernimmt die Berechtigungen einer Basisentität:
define role ZC_SalesOrder { grant select on ZC_SalesOrder where inherits_all;}Dies bedeutet: Der Projection View erbt die DCL des zugrundeliegenden Interface View.
Kontextabhängige Berechtigungen
Benutzerattribute
define role ZI_Employee { grant select on ZI_Employee where PersonnelArea IN aspect pfcg_auth( PLOG, PERSA, ACTVT = '03' ) or EmployeeID = $session.user;}Systemvariablen
| Variable | Beschreibung |
|---|---|
$session.user | Aktueller Benutzer |
$session.client | Aktueller Mandant |
$session.system_date | Systemdatum |
$session.system_language | Anmeldesprache |
define role ZI_PersonalData { grant select on ZI_PersonalData where CreatedBy = $session.user or Visibility = 'PUBLIC';}Access Control am View aktivieren
Der CDS View muss die Access Control Prüfung aktivieren:
@AccessControl.authorizationCheck: #CHECKdefine view entity ZI_SalesOrder as select from zsalesorder{ key SalesOrderID, SalesOrganization, Customer, NetAmount}authorizationCheck-Optionen
| Wert | Beschreibung |
|---|---|
#CHECK | DCL wird geprüft, Warnung wenn keine DCL existiert |
#NOT_REQUIRED | Keine Prüfung erforderlich |
#NOT_ALLOWED | DCL darf nicht existieren |
#PRIVILEGED_ONLY | Nur privilegierter Zugriff erlaubt |
Privilegierter Zugriff
Für Systemoperationen kann die Access Control umgangen werden:
" Mit privilegiertem Zugriff (DCL wird ignoriert)SELECT * FROM zi_salesorder WITH PRIVILEGED ACCESS INTO TABLE @DATA(lt_orders).
" Normaler Zugriff (DCL wird angewendet)SELECT * FROM zi_salesorder INTO TABLE @DATA(lt_orders_filtered).Wann privilegierten Zugriff verwenden?
- Batch-Verarbeitung: Hintergrundjobs ohne Benutzerkontext
- Systemintegration: RFC/API-Aufrufe aus anderen Systemen
- Reporting: Aggregierte Auswertungen
- Administration: Systemweite Operationen
Hierarchische Views
Bei View-Hierarchien wird die DCL auf jeder Ebene geprüft:
ZC_SalesOrder (Projection) ↓ Prüft eigene DCL (kann inherit nutzen)ZI_SalesOrder (Interface View) ↓ Prüft eigene DCLZSALESORDER (Tabelle)Best Practice: DCL-Strategie
-- Interface View: Volle Berechtigungsprüfungdefine role ZI_SalesOrder { grant select on ZI_SalesOrder where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );}
-- Projection View: Erbt von Interface Viewdefine role ZC_SalesOrder { grant select on ZC_SalesOrder where inherits_all;}Vergleich zu klassischen Authority-Checks
Klassischer Ansatz
METHOD get_sales_orders. " Manuell Berechtigung prüfen AUTHORITY-CHECK OBJECT 'V_VBAK_VKO' ID 'VKORG' FIELD lv_sales_org ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0. RAISE EXCEPTION TYPE cx_no_authority. ENDIF.
" Dann Daten lesen SELECT * FROM zsalesorder WHERE vkorg = @lv_sales_org INTO TABLE @rt_orders.ENDMETHOD.CDS Access Control Ansatz
METHOD get_sales_orders. " DCL prüft automatisch - nur berechtigte Daten zurückgegeben SELECT * FROM zi_salesorder INTO TABLE @rt_orders.ENDMETHOD.Debugging und Analyse
Access Control Trace
Im ADT kann der Access Control Trace aktiviert werden:
- Window → Show View → Other → Access Control Trace
- Trace starten
- View abfragen
- Trace analysieren
SQL Statement analysieren
" Generated SQL mit DCL-Bedingungen anzeigenDATA(lo_sql) = cl_sql_statement=>create_for_cds_entity( iv_cds_entity = 'ZI_SALESORDER' ).
DATA(lv_sql) = lo_sql->get_native_sql( ).Performance-Aspekte
Index-Nutzung
DCL-Bedingungen werden in WHERE-Klauseln übersetzt. Für gute Performance:
-- Gut: Feld mit Indexdefine role ZI_Order { grant select on ZI_Order where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );}
-- Schlecht: Komplexe Ausdrücke ohne Indexdefine role ZI_Order { grant select on ZI_Order where SUBSTRING( OrderNumber, 1, 2 ) = 'AB';}Pfad-Ausdrücke optimieren
-- Performance: Kurze Pfade bevorzugenwhere _Order.CompanyCode = ...
-- Weniger performant: Tiefe Pfadewhere _OrderItem._Order._Customer._Country.Region = ...Häufige Muster
Eigene Daten sehen
define role ZI_MyDocuments { grant select on ZI_MyDocuments where CreatedBy = $session.user or AssignedTo = $session.user;}Öffentliche und eigene Daten
define role ZI_Announcement { grant select on ZI_Announcement where Visibility = 'PUBLIC' or ( Visibility = 'PRIVATE' and Owner = $session.user );}Zeitbasierte Berechtigung
define role ZI_Campaign { grant select on ZI_Campaign where ValidFrom <= $session.system_date and ValidTo >= $session.system_date;}Best Practices
| Empfehlung | Begründung |
|---|---|
| DCL am Interface View definieren | Zentrale Stelle für Berechtigungslogik |
inherits_all für Projections | Konsistente Berechtigungen |
| Index auf Berechtigungsfelder | Performance bei großen Datenmengen |
| PFCG-Objekte wiederverwenden | Integration mit Rollenverwaltung |
#CHECK als Standard | Sicherheit durch Pflichtprüfung |
| Pfade kurz halten | Bessere Performance |
| Privileged Access sparsam einsetzen | Sicherheitsrisiko minimieren |
Zusammenfassung
CDS Access Control mit DCL bietet:
- Deklarative Berechtigungen: Regeln direkt am CDS View definiert
- Automatische Prüfung: Kein Vergessen von Authority-Checks möglich
- PFCG-Integration: Nutzung bestehender Berechtigungsobjekte
- Pfad-Ausdrücke: Berechtigungen über Assoziationen prüfen
- Performance: Optimierung durch DB-Pushdown
DCL ist der moderne Ansatz für Datensicherheit in ABAP Cloud und sollte für alle CDS Views mit sensiblen Daten verwendet werden.
Weiterführende Themen
- RAP Grundlagen - Basis-Konzepte von RAP
- CDS Views Grundlagen - CDS View-Definitionen
- Feature Control & Side Effects - Dynamische UI-Steuerung