BTP - Berechtigungsobjekt
Wie legen wir im ABAP Environment ein Berechtigungsobjekt an und grenzen die Daten im Core Data Service ab? Schauen wir uns einmal den Prozess und die Objekte dazu an und wie wir wieder an die Daten kommen.
Inhaltsverzeichnis
In dieser Folge schauen wir uns an, wie wir ein Berechtigungsobjekt im ABAP Environment anlegen und dieses verwenden, um Daten in einem Core Data Service abzugrenzen, um später unsere App besser steuerbar zu machen.
Einleitung
Dabei erweitern wir unsere Sales App, die wir bereits in vielen vorhergehenden Artikeln angelegt und erweitert haben. Idee ist es, die Daten in der Anwendung abzugrenzen, sodass der Mitarbeiter nur mit den für ihn berechtigten Daten arbeiten kann. Dazu benötigen wir im ersten Schritt ein klassisches Berechtigungsobjekt, um die Daten und die Visibilität abzugrenzen.
Authorization Field
Im ersten Schritt brauchen wir ein Berechtigungsfeld, welches unsere Einschränkung auf einem Feld zulässt. Grundsätzlich können wir hier Felder aus dem Standard wiederverwenden, wenn wir die entsprechenden Informationen auch in unserer Anwendung haben. In diesem Fall wollen wir auf den Partner einschränken, der Teil der Daten innerhalb der Sales App ist. Das heißt, wir legen für das entsprechende Datenelement, das wir für die Partner angelegt haben, ein neues Berechtigungsfeld an.
Im unteren Teil können wir eine Tabelle zuordnen, die Informationen für das Feld liefert, um später in der Pflege der Berechtigungen eine Auswahl zur Verfügung zu stellen. Über den Button "Search Help" können wir prüfen, welche Werte gezogen werden, die später der Berechtigungskollege zum Pflegen zur Verfügung hat. Hier müssen wir auch keine Tabelle angeben, wenn wir zum Beispiel ein Datenelement verwenden, welches eine Fix Value Domain hat. Dann werden automatisch die Werte dieser Domain genauso wie die Texte herangezogen und später in der Pflege angeboten.
Authorization Object
Schauen wir uns das wichtigste Element, das Berechtigungsobjekt, in diesem Kapitel an und wie wir die Einstellungen daran vornehmen können.
Anlage
Beim nächsten Schritt benötigen wir das eigentliche Berechtigungsobjekt. In der klassischen Welt konnten wir dies über die SU21 anlegen. In der neuen Welt steht uns dafür keine Transaktion zur Verfügung, sondern wir müssen das Element ganz normal über die ABAP Development Tools anlegen. Außer dem eigentlichen Element, welches relativ kurz ist, und der Beschreibung müssen wir keine weiteren Informationen mitgeben, um das Element anzulegen.
Objekt
Im eigentlichen Berechtigungsobjekt stehen uns dann verschiedene Informationen zur Verfügung. So haben wir im oberen Teil erst einmal allgemeine Informationen, um welchen Typ von Berechtigungsobjekt es sich handelt. Im mittleren Teil finden wir die verschiedenen Felder, so wie wir zum Beispiel vorher unser Feld angelegt haben für die Partner-ID. Grundsätzlich ist es Best Practice, die Aktivität auch mit aufzunehmen. Im unteren Teil finden wir dann die verschiedenen Aktivitäten, die für das Objekt aktiviert sind. Diese können wir weiter granular aussteuern. Mehr dazu im nächsten Abschnitt.
Unserem aktuellen Berechtigungsobjekt fügen wir nun unser neues Berechtigungsfeld hinzu, um später zusammen mit der Aktivität die Einschränkung vornehmen zu können. Die verschiedenen Aktivitäten sind soweit schon korrekt ausgeprägt und lassen wir erst einmal so.
Aktivität
Die Aktivitäten finden sich eigentlich in jedem Berechtigungsobjekt und steuern die verschiedenen Szenarien, wie wir mit den Daten interagieren. So ist zum Beispiel der Standard in den meisten Fällen 01 für Anlegen, 02 für Ändern und 03 für die Anzeige. Zusätzlich gibt es weitere Aktivitäten wie 06 zum Löschen oder 16 zum Ausführen. Die Aktivitäten sind standardisiert, sodass jedem Administrator und Entwickler sofort klar ist, was er kann, wenn er die Aktivität sieht. Deshalb ist diese Information auch wichtig, weil wir in den meisten Fällen, wenn wir mit Daten arbeiten, nicht nur die Anzeigeberechtigung einschränken, sondern zum Beispiel auch festlegen, wie wir mit den Daten interagieren können, ob wir diese ändern dürfen oder ob wir sie zum Beispiel löschen dürfen, wobei das Löschen in den meisten Fällen nur Administratoren möglich ist.
Core Data Service
Nachdem wir das Berechtigungsobjekt angelegt haben, wollen wir es auch direkt verwenden. Dafür passen wir unseren Core Data Service an und schauen uns damit die Änderung innerhalb des Prozesses an.
Access Control
Erweitern wir nun unser Access Control, welches aktuell nur als Dummy ausgeprägt wurde, aber immerhin schon vorhanden ist. Dazu fügen wir in die WHERE-Bedingung das Partnerfeld ein und führen eine Berechtigungsprüfung mit PFCG_AUTH durch. Dabei geben wir als Erstes das Berechtigungsobjekt an, gegen das wir prüfen, als Zweites die verschiedenen Felder, gegen die wir die Datenbank matchen, und als Drittes können wir die Aktivität angeben, welche wir mit einem Fixwert versorgen, in diesem Fall 03 für die Anzeige.
@EndUserText.label: 'ZBS_R_SASALE'
@MappingRole: true
define role ZBS_R_SASALE {
grant select on ZBS_R_SASALE
where ( PartnerNumber ) = aspect pfcg_auth( ZBSDMOPART, ZBSDMOPART, ACTVT = '03' );
}
Vererbung
Über die Vererbung innerhalb der Core Data Services wird dann die Berechtigungsprüfung auch an unseren Consumption View weitervererbt. Das heißt, wenn wir nun unsere Anwendung einmal ausführen und uns die Daten anzeigen lassen, werden wir feststellen, dass wir aktuell gar keine Daten mehr sehen, da wir keine Berechtigung haben, diese Informationen einzusehen. Dies ist der erste gute Test, um nachzuvollziehen, ob unsere Berechtigungsprüfung auch greift.
Zugriff
Da wir auf der untersten Ebene die Berechtigungsprüfung implementiert haben, erhalten wir auch keine Daten, wenn wir den Data Preview (F8 im CDS) direkt aus dem Core Data Service heraus aufrufen. Auch im Data Preview wird die Berechtigungsprüfung bzw. das Access Control herangezogen und wir sehen nur die Daten, für die wir auch wirklich berechtigt sind.
SQL Console
Allerdings können wir hier als Entwickler einen kleinen Trick heranziehen. Dazu gehen wir aus der Data Preview in die SQL-Konsole, dies ist über den Button im oberen Teil möglich, und ergänzen dann am Statement den Zusatz WITH PRIVILEGED ACCESS, um die Berechtigungsprüfung auszuschalten und den direkten Zugriff auf alle Daten zu erhalten. Auf der rechten Seite in der Data Preview werden dann alle Datensätze geladen, die auf der Datenbank vorhanden sind.
Hinweis: Wichtig ist dabei zu beachten, dass du den Zusatz WITH verwendest. Dieser ist in der SQL-Konsole nötig. Wenn du Statements bereits in ABAP verwendest, wird PRIVILEGED ACCESS verwendet, um im SELECT auf alle Daten zugreifen zu können.
Vollständiges Beispiel
Das vollständige Beispiel findest du in GitHub im entsprechenden Paket für die Sales App. Die Änderungen aus diesem Artikel findest du in diesem Commit und kannst damit die Änderungen, plus die Zusatzinformationen, nachvollziehen.
Fazit
Neben einer guten Anwendung ist auch ein gutes Berechtigungskonzept entscheidend, wenn eine Anwendung gut und sicher werden soll. Das Berechtigungsobjekt ist dabei der erste Schritt, um die Daten abzusichern und standardisierte Zugriffe zu ermöglichen. Dabei solltest du neben dem eigentlichen Berechtigungsfeld auch die Aktivität pflegen, welche in fast jedem Berechtigungsobjekt angeboten wird und zur Verfügung steht, um auch die verschiedenen Aktionen abbilden zu können.
