Authentifizierungsoptionen für Services

Es gibt mehrere Möglichkeiten, wie ein Service die Authentifizierung mit Cloud-API ausführen kann.

Eigenständiger Service

Ein Service kann sich als eigenständiger Service authentifizieren. In diesem Fall erfolgt der Aufruf durch den Service selbst. Der Aufruf wird nicht als bestimmte Person oder im Namen einer bestimmten Person ausgeführt. Der Service führt den Aufruf nicht mit einem in PolicyCenter gespeicherten Servicekonto aus.

PolicyCenter bezeichnet einen einzelnen internen Benutzer als „Proxy-Service-Benutzer“ für alle eigenständigen Serviceaufrufe. Dieser Proxy-Service-Benutzer wird an die eigenständige Servicesitzung angehängt. Wenn durch den Aufruf ein Objekt erstellt oder geändert wird, wird der Proxy-Service-Benutzer als eingetragener Benutzer verzeichnet.

Der Hauptvorteil dieses Ansatzes besteht darin, dass Sie Authentifizierungs- und Autorisierungsinformationen nur auf der Serviceebene verwalten müssen. Es ist nicht erforderlich, Benutzerkonten, Benutzerberechtigungen oder zusätzliche Zuordnungen zu erstellen und zu verwalten.

Der Hauptnachteil besteht darin, dass alle eigenständigen Serviceanrufe einen einzigen Proxy-Service-Benutzer teilen. Wenn ein eigenständiger Serviceaufruf ein Objekt erstellt oder ändert, kann möglicherweise nicht ermittelt werden, welcher Service den Aufruf getätigt hat.

Service mit Benutzerkontext

Ein Service kann sich mit Benutzerkontext authentifizieren. In diesem Fall gibt der Service Informationen über sich selbst an. Der Aufruf enthält darüber hinaus einen GW-User-Context-Header, der Informationen über einen bestimmten Benutzer bereitstellt. Der Benutzer muss nicht unbedingt in der PolicyCenter-Datenbank vorhanden sein. Der Aufruf kann nur die Dinge tun, die sowohl der Service selbst als auch der Benutzer selbst tun könnte.

Der angegebene Benutzer kann ein interner Benutzer sein (ein Benutzer, der in der PolicyCenter-Datenbank enthalten ist). In diesem Fall wird dieser interne Benutzer an die Sitzung angehängt. Wenn durch den Aufruf Daten erstellt oder geändert werden, wird der Benutzername als eingetragener Benutzer verzeichnet.

Der angegebene Benutzer kann ein externer Benutzer sein (ein Benutzer, der nicht in der PolicyCenter-Datenbank enthalten ist). PolicyCenter weist einen einzelnen internen Benutzer als „externen Proxy-Benutzer“ für alle Services mit Aufrufen im Benutzerkontext aus, die auf externe Benutzer verweisen. Wenn der angegebene Benutzer ein externer Benutzer ist, wird der externe Proxy-Benutzer an die Sitzung angehängt. Wenn durch den Aufruf ein Objekt erstellt oder geändert wird, wird der externe Proxy-Benutzer als eingetragener Benutzer verzeichnet.

Der Hauptvorteil dieses Ansatzes besteht darin, dass ein einzelner Service Aufrufe im Namen verschiedener Benutzer senden kann. Sie können den Zugriff auf der Serviceebene festlegen. Sie können aber auch den Zugriff für jeden zugehörigen Benutzer weiter steuern.

Hierbei gibt es zwei Hauptnachteile. Erstens müssen Sie die Zugriffsinformationen auf zwei Ebenen verwalten, auf der Serviceebene und auf der Benutzerebene. Zweitens kann ein Service einen beliebigen Benutzer in seiner Kopfzeile angeben. Es gibt keine Möglichkeit, die Verwendung eines bestimmten Benutzersatzes durch einen bestimmten Service einzuschränken.

Service mit Servicekontozuordnung

Ein Service kann sich mit Servicekontozuordnung authentifizieren. In diesem Fall wird der Service automatisch einem „Servicekonto“ zugeordnet. Die Zuordnungsinformationen werden an anderer Stelle in der Umgebung angegeben. Das Servicekonto ist ein Benutzerkonto in der PolicyCenter-Datenbank, das nur vom Service und nicht von einer Person verwendet werden soll.

Der Hauptvorteil dieses Ansatzes besteht darin, dass Berechtigungen und Überprüfungen für den Anruf mit einem Servicekonto verknüpft sind, das in der PolicyCenter-Datenbank aufgeführt ist. Sie können für jeden Service ein anderes Servicekonto erstellen und die für jeden Service verfügbaren Berechtigungen genau steuern.

Der Hauptnachteil besteht darin, dass Sie Servicekonten in PolicyCenter für Aufrufe externer Anwendungen erstellen und verwalten müssen. Außerdem müssen Sie die Zuordnungsinformationen verwalten, die jeden Service seinem Servicekonto zuordnen.

Vergleich der verschiedenen Ansätze

In der folgenden Tabelle werden die jeweiligen Ansätze miteinander verglichen.

Eigenständiger Service Service mit Benutzerkontext Service mit Servicekontozuordnung
Stellt der Aufruf Informationen über den Service bereit? Ja, im JWT. Ja, im JWT. Ja, im JWT.
Muss für den Aufruf ein Benutzerkonto in der PolicyCenter-Datenbank vorhanden sein? Nein

Ja, wenn der zugehörige Benutzer ein interner Benutzer ist.

Nein, wenn der zugehörige Benutzer ein externer Benutzer ist.

 Ja. (Dieses Benutzerkonto ist das „Servicekonto“.)
Enthält der Aufruf Informationen über einen Benutzer oder ein Benutzerkonto? Nein Ja, im GW-User-Context-Header. Nein. Der Aufruf stellt eine Client-ID für den Service bereit, aber die Zuordnung der Client-ID zum Servicekonto wird an anderer Stelle gespeichert.
Auf welche Endpunkte kann der Aufruf zugreifen? Die für die API-Rollen des Services verfügbaren Endpunkte Die sowohl für die API-Rollen des Services als auch für die API-Rollen des Benutzers verfügbaren Endpunkte. Die für das Servicekonto verfügbaren Endpunkte.
Auf welche Ressourcen kann der Aufruf zugreifen? Alle Ressourcen (in der Basiskonfiguration). Die sowohl für den Service als auch den Benutzer verfügbaren Ressourcen. Die für das Servicekonto verfügbaren Ressourcen.
Auf was ist der Sitzungsbenutzer eingestellt? Den Proxy-Service-Benutzer.

Den internen Benutzer, wenn der zugehörige Benutzer ein interner Benutzer ist.

Den externen Proxy-Benutzer, wenn der zugehörige Benutzer ein externer Benutzer ist.

 Das Servicekonto.

Dieses Thema behandelt die Authentifizierung von Services mit Benutzerkontext.