Umgang mit eigenen Berechtigungsobjekten

Heute geht es um „eigene Berechtigungsobjekte“.

Eigene Berechtigungsobjekte  sind dann notwendig, wenn man z.B. eigene Programme entwickelt, in denen Berechtigungsprüfungen codiert werden sollen.  Zu einen kann man auf die Standardberechtigungen abprüfen, zum anderen ist es manchmal notwendig, sich eigenen Berechtigungsobjekte anzulegen, um die Sicherheit aufrecht zu erhalten.

Speziell geht es heute darum, derartige eigene Berechtigungsobjekte zu ändern. D.h. man hat eine eigene Berechtigungsklasse angelegt und in dieser dann ein eigenes Objekt. Nun soll ein neuer Berechtigungswert dafür zusätzlich aufgenommen werden.

Das System lässt nur dann eine Änderung eines Berechtigungsobjektes zu, wenn dieses in keiner Rolle (bzw. Profil) vorkommt. Es wird schlicht eine Meldung ausgegeben, dass das Objekt in Gebrauch ist. Was ist zu tun?

Einmal müssen in allen Rollen in denen das Berechtigungsobjekt vorkommt, dieses zunächst auf inaktiv gesetzt werden, dann muss die Rolle generiert werden. Dies geschieht im Entwicklungssystem. Nun kann man das Berechtigungsobjekt ändern. Dafür wird ein Transportauftrag angelegt.

Falls das eigene Berechtigungsobjekt in einem Programm abgefragt wird, das einer Transaktion zugeordnet ist, dann gibt es für diese Transaktion ggf. auch einen SU24 – Eintrag. Durch den neuen Berechtigungswert im eigenen Berechtigungsobjekt, werden dann auch die Daten in der SU24 inkonsistent und müssen nachgebessert werden. Nach der Anpassung des Berechtigungsobjektes und der SU24 muss dann in der Rolle das Berechtigungsobjekt wieder aktiviert werden.

Wir haben also eine Anpassung des Berechtigungsobjekts, eine Programmänderung, eine Änderung in der SU24 und letztlich noch die veränderte Rolle. Jetzt kann es ggf. ein Problem geben:

Meist macht der Rollenadministrator keine Programmentwicklung. Andererseits wird der Entwickler keine Rechte für die SU24 und / oder die PFCG haben. Wenn nun der Entwickler das Berechtigungsobjekt anlegen soll und dies in seinen Transportauftrag aufnimmt, der Rollenadministrator die SU24 sowie die Rollenanpassung übernimmt, dann haben wir 2 Transportaufträge, die im Empfangssystem zu Problemen und Fehlermeldungen führen können.

Wird das Programm und das Berechtigungsobjekt in einem Transportauftrag gestellt und transportiert, kommt es im Empfangssystem, wo ja noch die alte Rolle gespeichert ist, zu einer Inkonsistenz beim Aufruf der PFCG auf die Rolle. Die PFCG lässt sich nicht mehr für diese Rolle aufrufen.

Deshalb müssen im Entwicklungssystem der Entwickler und der Rollenadministrator zusammenarbeiten. Am Besten stellt man alle Anpassungen der Beiden in einen Transportauftrag. Oder transportiert den Auftrag des Entwicklers mit der Berechtigungsobjektänderung und der Programmänderung zuerst, zeitnah gefolgt von der Änderung des Rollenadministrators betreffend der SU24 und der Rollenänderung.

Dieses Problem tritt nur dann auf, wenn ein bestehendes Berechtigungsobjekt nachträglich geändert werden soll. Bei neuen Berechtigungsobjekten tritt diese zeitliche Abhängigkeit nicht auf. Der Entwickler kann ein neues Berechtigungsobjekt anlegen und transportieren, erst später kann der Rollenadministrator das Berechtigungsobjekt für die Transaktion in die SU24 eintragen und die Rolle anpassen. Dieser Transport muss nicht gleichzeitig erfolgen.

Das Dumme dabei ist, dass die Transporte bei Inkonsistenz alle mit dem Returncode RC=0 enden, es also nicht auffällt, dass es im Empfangssystem zu einer Inkonsistenz gekommen ist.  Wenn allerdings nicht der Entwickler die Änderungen an den Berechtigungsobjekten macht, sondern der Rollenadministrator, dann könnte man das Programm alleine transportieren und danach erst die Berechtigungsobjekte, die SU24 sowie die Rolle.

Ok, das Programm ist in diesem Fall dann im Empfangssystem zunächst einmal nicht lauffähig, weil ja die Berechtigung fehlt, doch durch den 2. Transport des Rollenadminstrators wird die Anpassung vollständig und kann getestet werden.

Sie sehen also, dass man sich schon überlegen sollte, wer Anpassungen an welchen Berechtigungsobjekten durchführen darf.  Deshalb ist es notwendig, solche  Probleme im Berechtigungskonzept zu behandeln und damit die Berechtigungen des Entwicklers zu definieren.  Allenthalben wollen die Entwickler in der Entwicklungsumgebung meist SAP_ALL haben. Dieses obige Beispiel zeigt, dass derartiges zu ungeahnten Problemen führen kann.

Sie sehen außerdem, dass sich Inkonsistenzen wie in oben auch leicht transportieren lassen. Das kann Vorteile wie auch Nachteile haben.  Auf derartige Eigenheiten, verbunden mit dem Transport, werde ich in weiteren Artikeln noch eingehen. Denn oft ist gerade das Wissen, wie sich der Transport verhält,  nicht gleich parat.

Liebe Grüße

Bernd Klüppelberg

One Response to “Umgang mit eigenen Berechtigungsobjekten”

  1. Hallo

    der Beitrag ist gut. Was mir fehlt ist, wie man ein noch nicht vernetztes Berechtigungsobjekt:

    „Objekt XXX ist noch nicht exportiert (uneingeschränkt änderbar)“
    expotieren kann bzw. eingeschränkt änderbar machen kann

    VG L. Teichmann

Schreiben Sie bitte einen Kommentar





SAP Berechtigungen, -Konzepte, -Technik | System Beratung Bernd Klüppelberg