Nachfolgend wird das Benutzer- und Berechtigungsmanagement der SAP Business Technology Platform (BTP) vorgestellt. Durch übergeordnete Fragestellungen wird dabei auf die BTP als PaaS-Anwendung, dem Benutzer- und Berechtigungsmanagement sowie der Bedeutung der Architektur eingegangen.

Was ist die BTP?

Bei der Business Technology Platform, kurz BTP, handelt es sich um eine PaaS-Lösung der SAP. Die BTP soll, strategisch gesehen, als Bindeglied zwischen verschiedensten Lösungen im Cloud- und On-Premise-Bereich dienen. Weiterhin ist die BTP mit einer Vielzahl von Applikationen und Services ausgestattet, die eine schnelle Produktivität ermöglichen kann.

Bedeutung des Feature Set B?

Durch stetige Weiterentwicklung der BTP als zentrale PaaS-Lösung der SAP, wurden vorhandene Funktionalitäten architektonisch schnell ausgereizt. Um konkurrenzfähig zu bleiben und die BTP mit neuen Funktionen zu versehen, wurde das Feature Set B eingeführt. Merkmale des Feature Set B, im Gegensatz zum Feature Set A, sind:

• Einführung von Directories und Labels
• Einbindung von REST-APIs
• Verwendung eines BTP CLI als Alternative zur GUI
• Veränderungen an der Globalaccount Navigation
• Anpassungen bei den Entitlements
• Security-Anpassungen im Global- und Subaccount
• Veränderungen im Bereich der Identity Provider

Wie ist die Architektur der BTP?

Globalaccount

Der Globalaccount ist das zentrale Bindeglied zwischen der SAP und dem Unternehmen. Es ist vorgesehen, dass pro Unternehmen ein Globalaccount vorhanden ist, wobei ein Globalaccount keiner bestimmten Region zugeordnet ist. Historisch betrachtet ist es möglich, dass mehrere Globalaccounts innerhalb eines Unternehmens oder einer Group vorhanden sein können. Über den Globalaccount findet auch die Abrechnung zwischen der SAP und dem Unternehmen statt. Hierbei gibt es verschiedene Abrechnungsvarianten, die man wählen kann. Es kann aus drei Abrechnungsvarianten frei gewählt werden: Abonnementbasiert, Pay-As-You-Go und dem CPEA. Beim abonnementbasierten Modell wird ein Vertrag abgeschlossen, der einen festen Funktionsumfang zu einem fixen Entgelt vorsieht. Bei dem Modell “Pay-As-You-Go" bekommt der Nutzer sämtliche Funktionalitäten bereitgestellt. Monetarisiert wird lediglich das, was am Ende verwendet wird. Beim CPEA, dem Cloud Platform Enterprise Agreement, kauft das Unternehmen Credits, die wiederum in Funktionalitäten der BTP investiert werden können - ähnlich einem Guthabenvertrag. Ist die Abrechnungsfrage geklärt, geht es um die Administration des Globalaccounts, der immer von mindestens einem Administrator betreut wird. Dieser ist für die Erstellung neuer Directories, Subaccounts, damit einhergehender User, inklusive Berechtigungen und der Vergabe von Entitlements, einschließlich der zugehörigen Quotas verantwortlich. Unter Entitlements versteht man Funktionen, die erworben werden können, ähnlich wie bei Berechtigungen. Diese Entitlements können dann im Rahmen der zur Verfügung stehenden Quotas auf die Directories/Subaccounts verteilt werden.

Directories

Architektonisch gesehen folgen nach dem Globalaccount die Directories. Mit dem Feature Set B eingeführt, dienen Directories der organisatorischen Einteilung darunter liegender Subaccounts. Dadurch können vorhandene Organisationsstrukturen simpel abgebildet werden. Neben der organisatorischen Einteilung, können Directories auch administrative Eigenschaften annehmen. So ist es beispielsweise möglich, dass User und Ressourcen einem Directory zugeordnet werden können. Werden weitere Directories in die Hierarchie mit aufgenommen, die in einem direkten Bezug zueinanderstehen, so ist es nicht möglich, diese mit administrativen Eigenschaften zu versehen. Diese Möglichkeit ist lediglich einem Directory vorenthalten. Alle weiteren Directories die erstellt werden, haben lediglich organisatorische Funktionen. Wird hingegen ein weiteres Directory erstellt, dass in keinem direkten Bezug zu einem anderen Directory mit administrativen Funktionen steht, so kann auch hier eingestellt werden, dass administrative Funktionen verwendet werden können. Darunter liegende Subaccounts können dann nur auf die vorgegebenen Ressourcen und Benutzer zurückgreifen. Auch wenn „darüber“ im Globalaccount weitere Benutzer und Ressourcen vorhanden sind. Ähnlich wie bei dem Globalaccount wird mindestens ein Administrator benötigt, um Subaccounts und User innerhalb dieses Directories zu verwalten.

Subaccount

Ein Subaccount kann als produktive Landschaft bezeichnet werden. Hier wird das Ganze mit Leben gefüllt und die operativen Tätigkeiten der Business User bzw. die administrativen Tätigkeiten der Platform User durchgeführt. Hierbei gilt es zu berücksichtigen, dass es verschiedene Faktoren gibt, die es zu beachten gilt, wenn ein Subaccount angelegt werden soll. Als erstes muss festgelegt werden auf welchem Stack der Subaccount laufen soll. Zur Auswahl stehen Multi-Environment oder Neo. Bei Auswahl des Multi-Environment, was strategisch gesehen von der SAP forciert wird, werden Server bei verschiedenen Hyperscalern gehostet. Zur Auswahl stehen der Amazon Web Service (AWS), Google Cloud Platform und Microsoft Azure mit diversen Lokalitäten, je nach Standort des Unternehmens. Als zusätzlicher Hyperscaler kann auf Nachfrage die AliCloud bei der SAP beantragt werden. Ein weiterer Vorteil des Multi-Environment ist, dass verschiedene Entwicklungsumgebungen parallel verwendet werden können, um operativ tätig zu werden. Von der CloudFoundry über Kyma oder ABAP ist somit das Multi-Environment ideal aufgestellt, um sich den jeweiligen Anforderungen anzupassen. Entscheidet man sich für das Neo-Environment, gibt es zu beachten, dass Neo ausschließlich von SAP selbst angeboten wird. Somit wird der Subaccount auf Servern von SAP gehostet. Ferner muss berücksichtigt werden, dass das Neo-Environment lediglich bei bereits bestehenden Verträgen ausgewählt werden kann. Entscheidet sich ein Unternehmen neu in die Welt der BTP einzusteigen, ist das Multi-Environment vorgegeben.

Welche Arten von Benutzern gibt es in der BTP?

Unterschieden wird zwischen zwei Arten von Benutzern, den Business Usern und den Platform Usern: Business User benutzen bereitgestellte Anwendungen und Services, um auf der BTP produktiv tätig zu werden. Dies setzt voraus, dass diese über die notwendigen Berechtigungen verfügen. Anwendungsentwickler erstellen daher für jede Anwendung diverse Security Artefakte. Diese Artefakte werden wiederum von Administratoren dazu verwendet, Rollen zu erstellen und Role-Collections zuzuweisen, um dann Benutzern oder Benutzergruppen zuzuordnen. Platform User sind keine produktiven Benutzer. Bei dieser Gruppe von Benutzern handelt es sich um Entwickler, Administratoren sowie Benutzer für den App-Support. Je nach vergebener Berechtigung, ist ein Benutzer dann dazu in der Lage, über die vorherrschende Architektur zu administrieren bzw. Einsicht zu erhalten.

Der Arten von Berechtigungen innerhalb der BTP?

Roles beschreiben eine Funktion, die einen Benutzer für eine Tätigkeit innerhalb der BTP berechtigt.  Rollen werden jedoch nicht „lose“ an die Benutzer gekoppelt. Eine Vergabe erfolgt in Form von Role-Collections, einer funktionalen Bündelung verschiedener Rollen.

Wo müssen Benutzer und Berechtigungen gepflegt werden?

Über die gesamte Architektur müssen die Benutzer und Berechtigungen gepflegt werden. Hat man im klassischen SAP-Bereich die Transaktion SU01 zur Benutzeradministration bzw. die PFCG zur Rollenpflege, muss vom Globalaccount über den Subaccount bis zum Space im CloudFoundry-Environment auf jeder Ebene der entsprechende Benutzer hinterlegt und mit entsprechenden Berechtigungen versehen werden. Es ist nicht ausreichend, wenn ein Benutzer auf Ebene des Globalaccount mit einer Berechtigung ausgestattet wird. Berechtigungen gelten immer nur für die jeweilige Hierarchiestufe. Soll ein Benutzer auf Ebene eines Subaccounts tätig werden, so ist dieser innerhalb des jeweiligen Subaccount anzulegen und mit der jeweiligen Berechtigung auszustatten und das für jeden Subaccount manuell. Ebenso verhält es sich auf Ebene der Spaces. Bei jedem Space der wiederrum in einem Subaccount vorhanden ist, muss die Zuordnung ebenfalls durch Benutzer und Berechtigung erfolgen.

Was sind Identity Provider?

Identity Provider (IdP) sind für die Verwaltung von Benutzerdaten verantwortlich. Darüber hinaus bieten verschiedene Identity Provider, neben der reinen Benutzerverwaltung, weitere Funktionalitäten an wie Single Sign-On, Social-Log-On oder Multifaktor-Authentication, um nur einige zu nennen.

Welche Arten von Identity Provider können in der BTP verwendet werden?

In der BTP können verschiedene Arten von IdP‘s verwendet werden. Voreingestellt ist der SAP ID-Service, als Default Identity Provider. Hier wird auf Benutzerdaten zurückgegriffen, die bereits bei der SAP hinterlegt sind. Darüber hinaus wird die SAP BTP mit einem weiteren Identity Provider ausgeliefert, der eine Alternative zum SAP ID-Service darstellt und weitere Funktionalitäten neben der reinen Benutzerverwaltung ermöglicht. Hierbei handelt es sich um den Identity Authentication Service. Führt ein Unternehmen jedoch die BTP neu ein, möchte es nicht unbedingt jeden Benutzer neu in der BTP anlegen müssen. Bei größeren Unternehmen ist das ein nicht zu unterschätzender administrativer Aufwand. Daher gibt es als dritte Möglichkeit, einen kundeneigenen Identity Provider zu integrieren. Hierfür kann der Identity Authentication Service als Proxy eingerichtet werden. Das Unternehmen ist dadurch in der Lage, auf die bereits vorhandenen Benutzerdaten zurückzugreifen und für die BTP zu verwenden.

Welche IdP können in welcher Ebene benutzt werden?

Identity Provider können sowohl als Platform-Identity-Provider oder als Anwendungs-Identity-Provider angelegt werden. Als Platform-IdP werden diese mit dem jeweiligen Subaccount verknüpft, wo hingegen als Anwendungs-IdP eine direkte Verknüpfung mit der jeweiligen Anwendung im Subaccount hergestellt wird.

War das schon alles?

Kurz: Nein! Die Thematik des Benutzer- und Berechtigungsmanagement im Zusammenhang mit der BTP ist ein vielschichtiges Feld, das sich mit heterogenen Umgebungen auseinandersetzt. Thematisiert wurden hier Bedeutung der Architektur im Zusammenhang mit Benutzern und Berechtigungen, direkt auf der Business Technology Platform. Ferner wurde auch die theoretische Einbindung alternativer Identity Provider kurz vorgestellt. Sollten Fragen zu den vorgestellten Inhalten offen sein, wird auf das zugehörige Webinar zu dem Thema verwiesen. Alternativ kann aber auch gerne Kontakt über folgende Mailadresse (Mail) aufgenommen werden, um Fragen zu beantworten. Darüber hinaus möchten wir noch einen Ausblick auf zukünftige Artikel zum Kontext der BTP-Security verweisen. Diese geplanten Artikel werden sich mit weiteren Aspekten des Benutzer- und Berechtigungsmanagements der BTP befassen. Also bleiben Sie gespannt!