SAP hat mit 7.50 (bzw. die Rede war auch manchmal schon mit 7.40 SP10 – kann ich aber aktuell nicht bestätigen) die CDS Views mit der DCL Data Control Language um die Möglichkeit von impliziten Berechtigungsprüfungen in einem CDS View erweitert. Klingt erstmal etwas trocken ist aber ziemlich genial, denn dadurch können nun Datenbankzugriffe auf Basis der Dateninhalte mit einem Authority-Check versehen werden.
Und das Coole ist, dass dies einfach und schnell erledigt ist!
Nehmen wir an, wir haben eine Tabelle mit ein Feld SOURCE in dem auf der Datenbank die Werte 0001, 0002 und Space vorkommen, im konkreten Fall hab ich einfach die BUT000 genommen wo wir genau solche Einträge vorfinden:
Die Idee ist nun, dass wir einen CDS View auf die 4 Felder anlegen und über eine PFCG Rolle steuern dass nur Werte mit der SOURCE 0001 gelesen werden.
CDS View
Zuerst legen wir jetzt mit Eclipse einen neuen CDS View mit der DDL (Data Definition Language) an. Mit den Feldern PARTNER, SOURCE, MC_NAME1 und MC_NAME2:
Für jene die noch nicht mit Eclipse gearbeitet haben: DDL und DCL für CDS Views können derzeit nur mit Eclipse bearbeitet werden. Ein persönlicher Tipp: Eclipse wird immer wichtiger. Die CDS Views sind der Anfang. Ohne Eclipse keine CDS Views!
Natürlich gibt es bei einer DDL Beschreibung viele Annotation-Möglichkeiten, im Hinblick auf eine implizite Berechtigungsprüfung ist auf nachfolgende Annotation zu achten:
@AccessControlauthorizationCheck: #CHECK
die Berechtigungsprüfung durch eine DCL Access Control ermöglicht wird. #CHECK ist der Defaultwert (sprich auch ohne Angabe wäre der Wert auf #CHECK gestellt), weiter Eingabemöglichkeiten sind #NOT_REQUIRED und #NOT_ALLOWED.
#CHECK – Eine implizite Berechtigungsprüfung wird vorgenommen. Wenn zu dem View keine DCL existiert, kommt es bei der Syntaxprüfung zu einer Warnung.
#NOT_REQUIRED – Gleich wie #CHECK, jedoch ohne Warnung bei der Syntaxprüfung
#NOT_ALLOWED – Es wird keine Zugriffskontrolle vorgenommen.
Weitere Informationen zu den DDL Annotations sind bitte der SAP Online Dokumentation zu entnehmen.
PFCG Berechtigungsobjekt
Nun müssen wir ein Berechtigungsobjekt wählen oder neu erstellen. Ich hab ein neues Berechtigungsobjekt ZDEMODCL mit 2 Feldern ZBU_SOURCE und ACTVT erstellt. ZBU_SOURCE steht für den 4stelligen Wert in SOURCE. ACTVT verwende ich um die Aktivität 03 (03 = lesen) abzubilden:
DCL Rolle
Als Nächstes erstellen wir mit der DCL (Data Control Language) die Berechtigungsprüfung auf den View. Dazu müssen wir wieder nach Eclipse wechseln und ein DCL Objekt anlegen:
Dadurch wird eine DCL Rolle mit dem Namen ZCDSDCLDEMO_NAME definiert. In einer CDS Rolle können eine oder mehrere CDS Entitäten mit CDS Zugriffskontrollen versehen werden. Im konkreten Beispiel wird die CDS Entität ZCDSDEMOENT verwendet. Dies geschieht durch die Angabe GRANT SELECT ON ZCDSDEMOENT.
Nach der Angabe der CDS View muss eine WHERE-Klausel mit der Zugriffsbedingung folgen. Dies kann wiederum als Literalen (z.B. SOURCE = ‘0001‘) bestehen oder wie im obigen Beispiel aus einer PFCG-Bedingung.
PFCG-Bedingung
Eine PFCG-Bedingung wird mit ASPECT PFCG_AUTH ( <authorization_object>, [ field ], [ field ], …. ) definiert. Die Felder der PFCG Bedingung können gemappte Felder aus der WHERE-Klausel oder Literale wie z.B. ‘03‘ sein.
DCL Annotations
Mit der Annotation @MappingRole: true wird die Rolle gegen alle User automatisch geprüft. Weitere Werte sind derzeit hier zum aktuellen Zeitpunkt noch nicht möglich.
Die Annotation @EndUserText.label: ‘zrole_demo‘ ist der übersetzbare Kurztext der Rolle.
Berechtigungszuordnung
Wenn wir die obigen Schritte beendet haben, jedoch noch keine Berechtigungsvergabe an einen User vorgenommen haben, wird dieser bei einem DB Zugriff auf den CDS View – wie erhofft – keinerlei Daten zurückbekommen.
Erst wenn wir dem User eine Berechtigung für das Berechtigungsobjekt Z_DCL_DEMO erteilen werden die erlaubten Daten bei SELECT-Zugriffen zurückgeliefert.
SELECT Zugriff auf CDS Entity und CDS DB View
Bei allen ABAP SELECT Zugriffen auf die CDS Entität erfolgt nun die implizite Berechtigungsprüfung. Hingegen bei der obsoleten Möglichkeit des Zugriffs auf den CDS DB View erfolgt diese implizite Prüfung nicht. Aus dem Grund sollten die CDS DB Views auch nicht mehr verwendet werden und wurden von SAP auch als obsolet gekennzeichnet.
Nachfolgend ein Auswertungsergebnis auf ein die CDS Entität (links) und den CDS DB View (rechts). Wie erwartet wurde die Ergebnismenge der CDS Entität implizit auf die SOURCE 0001 gefiltert.
Troubleshooting & Testing
Manchmal schlagen sich Änderungen in den DCL Objekten nicht „durch“. Für DCL Analysen kann die Transaktion SACMDCLS verwendet werden. Dort sieht man detaillierte Informationen zu einem DCL Objekt und kann ggf. DCL Artefakte neu generieren.
Weiters ist auch noch die Transaktion SACMSEL interessant. Mit der kann der DCL Zugriff getestet werten.
