BTP - Restriction Type
Berechtigungen im ABAP Environment über eine IAM App vergeben ist schnell gemacht, doch wie sieht es mit einer variablen Pflege der Elemente pro Business Role aus? Schauen wir uns dazu die Varianten und die Abgrenzung zwischen Write und Read an.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die Abgrenzung der Restriction Types an und wie diese mit den Berechtigungsobjekten zusammenspielen. Dabei werden wir die Berechtigungen dynamisch über die Business Roles vergeben.
Einleitung
Im letzten Artikel haben wir unsere Sales App erweitert und die Berechtigungen auf Ebene des Core Data Services eingeschränkt. Dabei haben wir ein klassisches Berechtigungsobjekt angelegt, welches wir dann im Core Data Service über das Access Control abgefragt haben. Ein weiterer Schritt ist aber nun, die Berechtigungen dynamisch in der eigentlichen Rolle des Users zu pflegen, sodass der Berechtigungsadmin die Möglichkeit hat, die Werte über die UI einzuschränken und nicht nur über die Entwicklungsobjekte.
Herausforderung
Die eigentliche Berechtigung vergeben wir in der IAM-App. Dazu gibt es einen Reiter für "Authorizations", wo wir unser eigentliches Berechtigungsobjekt eintragen können und hier Werte definieren, um eine Abgrenzung vorzunehmen. Diese Werte sind in den meisten Fällen jedoch statisch und an diese IAM-App gebunden und erlauben keine weitere Pflege des Berechtigungsadmins.
Aktivieren wir die IAM-App und starten dann noch einmal den Core Data Service, so erhalten wir nun alle Datensätze, die diesem Business Partner entsprechen. Das liegt daran, dass diese IAM-App einem Business Catalog zugeordnet ist, der Business Catalog einer Business Role und diese Rolle unserem User-Stammsatz bereits zugeordnet wurde. Damit erhalten wir automatisch die Berechtigung, die wir hier eingetragen haben.
Restriction Field
Vielleicht ist dir dieser Dialog schon beim letzten Mal aufgefallen, denn unter dem Berechtigungsfeld finden wir noch weitere Links, die zusätzliche Aktionen triggern können. Eine Aktion davon benötigen wir, nämlich die Anlage und Zuordnung zu einem Restriction Field. So wollen wir ein neues Restriction Field anlegen und direkt unser Berechtigungsfeld zuordnen.
Allerdings werden wir im ersten Schritt eine Fehlermeldung erhalten, wenn wir versuchen, den Wizard abzuschließen. Dieser weist auf fehlende Metadaten hin. Das kann daran liegen, dass unsere Tabelle nicht korrekt definiert ist, die unsere Wertehilfe erstellen soll. Denn wir haben im Berechtigungsfeld ein Datenelement angegeben, welches das System nun auch als Schlüsselfeld erwartet, um die Werte für die Zuweisung heranziehen zu können. Daher müssen wir noch einmal in die Zieltabelle gehen, in diesem Fall unsere Partnertabelle, und das Datenelement des Schlüsselfeldes von CHAR10 auf das Datenelement abändern.
Der Wizard sollte nun durchlaufen, uns ein Restriction Field erstellen und direkt das Berechtigungsobjekt zuordnen. Wenn wir das Objekt dann speichern, können wir auch hier den Button für "Search Help" verwenden und sollten nun eine Wertehilfe mit all unseren Werten aus der Hilfstabelle erhalten. Somit ist sichergestellt, dass die Werte auch später in unserer Fiori-Anwendung ausgewählt werden können.
Restriction Type
Im nächsten Schritt müssen wir einen Restriction Type anlegen, dieser entspricht dem Berechtigungsobjekt. So gehen wir in diesem Kapitel die Anlage und die Zuordnung einmal im Detail durch.
Anlage
Der Restriction Type kann über die normale Anlage erzeugt werden oder wir gehen wieder über den Link im Berechtigungsobjekt. In diesem Fall haben wir diesen Link geklickt, und es wird automatisch ein Restriction Type angelegt und das entsprechende Berechtigungsobjekt zugeordnet. Ebenfalls wird automatisch erkannt, dass es bereits Restriction Fields gibt, die dann automatisch auch dem Objekt zugeordnet werden. Somit sind alle Informationen innerhalb des Objektes vorhanden, und über den Button "Publish Locally" können wir das Objekt im System bekanntgeben.
Eine Zuordnung des Activity-Feldes (ACTVT) ist hier nicht nötig. Dies wird über das Framework gesteuert, ebenso wie die Zuordnung der Berechtigungen und Einzelwerte. Dies hat den Vorteil, dass es sich um ein Standardelement handelt, das in fast jedem Berechtigungsobjekt eingesetzt wird.
Zuordnung
Nun müssen wir den Restriction Type entsprechend dem Business Catalog zuordnen, damit wir die Pflege später durchführen können. Im Reiter "Restriction Types" findest du einen Button namens "Propose Restriction Types ...". Diesen kannst du klicken und erhältst einen Vorschlag für alle Restriction Types, die für die jeweiligen IAM-Apps verfügbar sind. Die Information leitet sich aus dem verwendeten Berechtigungsobjekt ab, entsprechend schaut das Tool im System, welche Berechtigungsobjekte den einzelnen IAM-Apps zugeordnet sind, ermittelt die zusätzlichen Restriction Types und bietet diese hier im Dialog an.
Wir bestätigen den Restriction Type, sodass er unten in der Liste aufgeführt wird, und setzen die Haken bei Write und Value Help, da wir diese Einstellung später auch über die Rolle pflegen lassen wollen. Bist du mit der Pflege fertig, musst du wieder ein "Publish Locally" durchführen, damit die Änderungen des Business Catalogs im Launchpad verfügbar gemacht werden.
Test
In diesem Kapitel führen wir die Änderung durch, pflegen unsere Berechtigungen im Launchpad und schauen uns die Daten zum Abschluss in unserer App an.
Pflege
Dazu gehen wir in unsere Business Role, die wir bereits in einem älteren Artikel angelegt haben, um hier die Berechtigungen pflegen zu können. Wichtig ist, dass der Business Catalog mit der entsprechenden IAM-App auch zugeordnet ist, damit Restriction Types gezogen werden können. Als Erstes müssen wir dazu auf der Rollenebene die Access Categories umstellen, und zwar auf Restricted, damit wir Werte einschränken können. Unrestricted bedeutet zum Beispiel, dass wir überall einen Stern haben und damit Zugriff auf Alles.
Im oberen Teil findest du dazu "Maintain Restrictions", über diesen Button gelangen wir auf eine neue Seite, auf der wir Änderungen vornehmen können. Hier sehen wir ebenfalls die Access Categories, die auf Restricted eingestellt wurden. Im unteren Teil sehen wir alle zugeordneten Restriction Types, die wir pflegen können. In der Mitte sehen wir die zwei verschiedenen Bedingungen, hier können wir die Zugriffe steuern. Auf der rechten Seite siehst du die Auswahl, wenn wir im Editier-Modus sind. Im oberen Teil kannst du dort auf Restricted oder Unrestricted setzen, um so zum Beispiel auch ein Sternchen (Wildcard) zu definieren. Oder du wählst die Werte in der Liste unten aus. Grundsätzlich sind auch Ranges möglich, diese haben wir aber im Objekt nicht aktiviert. Dies wird im Restriction Type gemacht.
Hier handelt es sich jeweils nur um Beispiele für einen unbeschränkten Zugriff. Grundsätzlich pflegen wir beide Werte für jeweils zwei Business Partner, die wir dann später in der Anwendung sehen und pflegen möchten. Denn grundsätzlich überschreibt die Einstellung oben für Read and Write die Einstellung unten, die nur Read beinhaltet. Würden wir dann oben eine Berechtigung für alles setzen, würde automatisch auch Lesen für alles möglich sein.
App
Gehen wir nun in unsere Fiori-App Global Sales und drücken auf "Go", um die Daten zu laden, werden jeweils nur drei Datensätze geladen. Dies entspricht den Datensätzen, für die wir Berechtigung zur Anzeige haben. Damit haben wir die Einstellung aus der IAM-App überschrieben und durch unseren Restriction Type ersetzt, sodass wir die beiden gepflegten Business Partner sehen.
Read or Write
Wie wird eigentlich der Unterschied zwischen Read- und Write-Aktivitäten festgelegt, da wir diese in der Business Role nicht pflegen? Grundsätzlich kommt diese Einstellung aus der Activity, in diesem Fall aus dem Berechtigungsobjekt. Dort hatten wir definiert, welche Aktivitäten für das Berechtigungsobjekt zur Verfügung stehen. Dort können wir auch die Access Categories überschreiben, die als Default festgelegt werden. So sehen wir zum Beispiel in der Liste, dass 03 als Read-Activity ausgegeben wird und 01, 02 und 06 jeweils als Write. Im Editiermodus hätten wir hier die Möglichkeit, zum Beispiel auch die Aktivität 06 auf Read zu setzen, was erst mal keinen Sinn ergeben würde, aber grundsätzlich möglich ist, um die verschiedenen Activities den Kategorien zuzuordnen.
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
Restriction Types sind wichtig, wenn wir dynamisch Berechtigungen über das Launchpad pflegen und vergeben wollen. Damit hat der Berechtigungsadmin am Ende die Möglichkeit, verschiedenen Rollen verschiedene Business Partner zuzuordnen, sodass ein User, der vielleicht Admin ist, alles sehen kann, aber die verschiedenen User in den verschiedenen Gruppen nur auf verschiedene Business Partner Zugriff haben. Dies ist jedoch nicht abhängig von einem Backend-Objekt, sondern kann dynamisch über die UI gepflegt werden.
