SU53 für SAP Cloud Platform Berechtigungen – welche Scopes habe ich?
Autor: Tobias Harmes | 1. September 2020
Wenn die Kachel beim Anwender nicht angezeigt wird oder der Entwickler nicht auf das Business Application Studio kommt, liegt es auch in der SAP Cloud Platform sehr oft an fehlenden Rechten. Doch wie findet man die aktuellen Berechtigungen des Anwenders heraus?
In der ABAP-Welt gibt die Transaktion SU53 Auskunft darüber, an welcher Berechtigungsprüfung der Anwender soeben gescheitert ist. In der SAP Cloud Platform auf Cloud Foundry gibt es leider keine Entsprechung. Hier müsste jede Applikation selbst entsprechende Fehlermeldungen ausgeben.
Who-Service – welche Scopes hat der Anwender bekommen?
Es gibt aber eine Funktion, die einem beim Entstören der Berechtigungen sehr helfen kann. Die „Who“-Auskunft des zuständigen XSUAA-Services. Und so sieht das zum Beispiel aus:
Neben dem IDP und anderen an die Applikation übermittelten User-Daten werden auch die „authorities“ aufgelistet. Die Scopes, die der Anwender in den jeweiligen Apps besitzt.
Wenn man sich auf Entwicklerseite die hinter dem XSUAA liegende xs-security.json ansieht, dann findet man die entsprechenden Scopes z.B. in den Role-Template-Abschnitten wieder.
Die Funktion zeigt mir also an, welche Scopes für welche Applikationen der gerade angemeldete User erhalten hat. So kann z.B. das erfolgreiche Mapping von Role Collections kontrolliert werden. Leider wird hier nicht aufgeführt, welche Role collections und Roles der Anwender genau zugeordnet bekommen hat, sondern nur die Essenz aus diesen Zuordnungen – die Netto-Liste der Application-Scopes sozusagen. Es ist ein wenig so, wie wenn Berechtigungsobjekte angezeigt werden würden, aber eben keine Rollennamen und Profile.
Wenn Corporate IDPs in Verbindung mit dem SAP Identity Authentication Service (IAS) verwendet werden, dann werden z.B. hier auch SAML issuer und SAML groups mit ausgewiesen. Das ist sehr nützlich, wenn man diese z.B. für die Role collection mappings verwendet.
Wo finde ich meine Who-URL?
Die notwendige URL basiert meistens auf der Subdomain des Subaccounts. Genau findet man ihn in der Service-Instanz des XSUAA:
(1) Vom Global Account auf den Subaccount und dort auf den entsprechenden Space wechseln
(2) Service Instances auswählen
(3) XSUAA Instanz auswählen
Dort findet man dann in den „sensitive data“ die richtige URL. In diesem Fall https://71afdef9trial.authentication.us10.hana.ondemand.com
Und dort hängt man jetzt das „/config?action=who“ an.
In diesem Beispiel also komplett https://71afdef9trial.authentication.us10.hana.ondemand.com/config?action=who
Übrigens: ein weiterer nützlicher URLs-Anhang in diesem Zusammenhang ist „/logout.do“ um sich auszuloggen.
Zu viel Berechtigungen
Zugegebenermaßen nicht so häufig, aber durchaus auch ein Thema: zu viel Berechtigungen. Wenn ich wissen will, welche Role collection meinem Anwender die Berechtigung auf ein Scope verschafft hat, dann muss ich aktuell praktisch alle Role collections betrachten, die eine passende Role enthalten. Wenn jede Applikation einen „Viewer“ mitbringt, ist Chaos in großen Spaces vorprogrammiert. Die richtige Version von „Viewer“ sehe ich dann nur, wenn ich in die Role Collection gehe:
Deshalb gilt auch hier: eine saubere Namenskonventionen schon bei der Entwicklung schont die Nerven hinterher bei den Berechtigungen – auch bei den Anwendern.
Ausblick
Kaum zu glauben, dass man sich mal nach der SU53 oder SU56 aus der normalen SAP ABAP-Welt sehnen würde. Ich hoffe, die Who-Übersicht zeigt irgendwann auch Role collections und Roles mit an. Schon jetzt ist es auf jeden Fall sehr nützlich im Anwendertest und im Support-Fall.