Übersicht über die Authentifizierung für eigenständige Services

Zur Authentifizierung gehören die Anmeldeinformationen und die Autorisierung. Die Authentifizierungsinformationen für Services werden in JWTs angegeben und Informationen aus diesen JWTs werden in den Protokollen aufgezeichnet.

Anmeldeinformationen

Wenn ein Service einen API-Aufruf ausführt, sendet der Service eine Client-ID und ein Client-Geheimnis an Guidewire Hub. Guidewire Hub authentifiziert den Service, indem es bestätigt, dass das Client-Geheimnis korrekt ist. Dies gilt für eigenständige Services, Services mit Benutzerkontext und Services mit Servicekontozuordnung.

Weitere Informationen zur Registrierung von Client-IDs und Client-Geheimnissen bei Guidewire Hub finden Sie unter Registrieren der aufrufenden Anwendung in Guidewire Hub.

Autorisierung

Endpunktzugriff für eigenständige Services

Der Endpunktzugriff definiert die Verhaltensweisen eines Endpunkts, die für einen Aufrufer verfügbar sind, genauer. Dazu gehören:

  • Welche Endpunkte und Ressourcentypen stehen dem Aufrufer zur Verfügung?
  • Welche Operationen kann ein Aufrufer am verfügbaren Endpunkt aufrufen?
  • Welche Felder kann der Aufrufer in den Anforderungs-Nutzdaten angeben oder in den Antwort-Nutzdaten abrufen?

Der Endpunktzugriff wird durch API-Rollen gesteuert. Eine API-Rolle ist eine Liste von Endpunkten, Operationen und Feldern, die für eine Reihe von Aufrufern über API-Aufrufe verfügbar sind. API-Rollen fungieren als Allowlists. Standardmäßig hat ein Aufrufer keinen Endpunktzugriff. Wenn der Aufrufer mit einer oder mehreren API-Rollen verknüpft ist, erhält er Zugriff auf die in jeder dieser API-Rollen aufgeführten Endpunkte, Operationen und Felder.

Theoretisch kann ein eigenständiger Service mit mehreren API-Rollen verknüpft werden. In der Regel erstellen Versicherer für jeden Service eine API-Rolle, die nur von diesem Service verwendet wird.

Bei einem eigenständigen Serviceaufruf überprüfen die System-APIs die API-Rolle(n), die dem Service zugewiesen ist bzw. sind. Der Aufruf hat Zugriff auf die in diesen Rollen angegebenen Endpunkte, Operationen und Felder. Als Beispiel folgende Annahme: Der externe Dokumentenmanagerservice von ACME hat die folgende API-Rolle mit folgendem Endpunktzugriff:

  • acme_externaldocumentmanager
    • GET /documents
    • POST /documents

Gehen wir dann davon aus, dass der externe Dokumentenmanagerservice von ACME einen eigenständigen Serviceaufruf durchführt. Der Aufruf hätte Zugriff auf GET /documents und POST /documents. Wenn es jedoch einen DELETE /documents-Endpunkt gäbe, hätte der Aufruf keinen Zugriff darauf, weil er nicht in der Rolle acme_externaldocumentManager angegeben wurde.

Weitere Informationen zur Konfiguration von API-Rollen finden Sie unter Endpunktzugriff.

Ressourcenzugriff für eigenständige Services

Der Ressourcenzugriff definiert für einen bestimmten Ressourcentyp, auf welche Instanzen dieser Ressource der Aufrufer zugreifen kann. Als Beispiel folgende Annahme: Es gibt einen GET /claims-Endpunkt, der für Versicherungsnehmer, Underwriter, Schadenregulierer und Serviceanbieter verfügbar ist. Alle diese Aufrufer können mit dem Endpunkt auf Ressourcen zugreifen, deren Typ claim ist. Keiner der Aufrufer kann jedoch auf alle Schadenfälle zugreifen. Zum Beispiel:

  • Einem Versicherungsnehmer werden möglicherweise nur die Schadenfälle angezeigt, die den von ihm gehaltenen Policen zugeordnet sind.
  • Einem Underwriter werden möglicherweise nur die Schadenfälle für die ihm zugewiesenen Policen angezeigt.
  • Einem Schadenregulierer werden möglicherweise nur die ihm zugewiesenen Schadenfälle angezeigt.
  • Einem Serviceanbieter werden möglicherweise nur die Schadenfälle angezeigt, denen eine Serviceanfrage zugewiesen ist.

Eine Ressourcenzugriffsstrategie ist ein Logiksatz, der angibt, auf welche Ressourcen ein Aufrufer zugreifen kann. Die Basiskonfiguration umfasst Ressourcenzugriffsstrategien für eigenständige Services. Diese Strategien beinhalten jedoch keine Ressourcenzugriffs-IDs und schränken den Service in keiner Weise ein. Sobald einem Service Zugriff auf einen Satz von Endpunkten gewährt wurde, kann der Service auf alle für diese Endpunkte verfügbaren Ressourcen zugreifen. Es wird erwartet, dass Services so konfiguriert werden, dass sie nur auf die den Umständen entsprechenden Ressourcen zugreifen.

Name der Strategie Rolle, die diese Strategie verwendet Für die Ressourcenzugriffs-ID wird angenommen... Gewährt Zugriff auf...
pc.​service Services Nicht zutreffend Alle Ressourcen

Weitere Informationen zum Verhalten des Ressourcenzugriffs finden Sie unter Ressourcenzugriff.

Proxy-Benutzerzugriff für eigenständige Services

Jeder Cloud-API-Aufruf erfolgt im Kontext einer Sitzung. Ein in der PolicyCenter Datenbank aufgeführter Benutzer muss an diese Sitzung angehängt werden. PolicyCenter kann diesen „Sitzungsbenutzer“ auf verschiedene Weise verwenden.

  • Wenn durch den Aufruf ein Objekt erstellt oder geändert wird, wird der Sitzungsbenutzer als CreateUser oder UpdateUser dieses Objekts aufgeführt.
  • Wenn der Aufruf eine Prüfung des Vollmachtsrahmens auslöst, werden die Vollmachtsrahmen des Sitzungsbenutzers überprüft.
  • Es besteht eine geringe Chance, dass der Aufruf eine Logik auslösen kann, bei der geprüft werden muss, ob der Aufrufer über eine bestimmte Systemberechtigung auf Domänenebene verfügt, z. B. über die Berechtigung, eine Aktivität zu besitzen. In diesem Fall werden die Systemberechtigungen des Sitzungsbenutzers überprüft.

Ein Proxy-Benutzer ist ein interner Benutzer, der einer Sitzung für einen API-Aufruf zugewiesen wird, der von einem externen Benutzer oder Service erfolgt. Proxy-Benutzer werden vom RestAuthenticationSourceCreatorPlugin-Plugin zugewiesen. Dieses Plugin gibt vier Proxy-Benutzer an. Einer von ihnen, der Proxy-Servicebenutzer, wird für eigenständige Serviceaufrufe verwendet.

  • Wenn durch den Aufruf ein Objekt erstellt oder geändert wird, wird der Proxy-Servicebenutzer als CreateUser oder UpdateUser dieses Objekts aufgeführt.
  • Wenn der Aufruf einen Vollmachtsrahmen oder eine Systemberechtigung auf Domänenebene auslöst, werden die Rahmen und Berechtigungen des Proxy-Servicebenutzers überprüft.

Weitere Informationen zu Proxy-Benutzern finden Sie unter Proxy-Benutzerzugriff.

JWTs für eigenständige Services

JSON-Webtoken (JWTs) enthalten Token-Claims. (Im JWT-Jargon werden diese einfach als „Claims“ bezeichnet. Um Verwechslungen mit Schadenfällen (engl. „claims“) im Sinne der Sach- und Unfallversicherung zu vermeiden, werden JWT Claims in dieser Dokumentation immer als „Token-Claims“ bezeichnet.) Ein Token-Claim ist eine zum Inhaber des Tokens bereitgestellte Information, z. B. der Name des Inhabers. Für die Bearer-Token-Authentifizierung werden Authentifizierungsinformationen in Token-Claims gespeichert.

Wenn ein Service einen eigenständigen Serviceaufruf ausführt, sind nur einige der Informationen im JWT spezifisch für die Cloud-API-Authentifizierung. Im Folgenden sind die Token-Claims in einem JWT für einen eigenständigen Serviceaufruf aufgeführt, die sich auf die Cloud-API-Authentifizierung beziehen.

"sub": "<clientId>",
"cid": "<clientId>", 
"scp": [
  "pc.service",
  "scp.pc.<serviceAPIRole>"
]
  • sub ist der Gegenstand des Tokens. Dieser wird auf die Client-ID des Services gesetzt.
  • cid ist die Client-ID des Services. Diese wird auch auf die Client-ID des Services gesetzt.
  • Der scp-Token-Claim hat mindestens die folgenden Einträge:
    • Den pc.service-Wert, der angibt, dass der Aufrufer ein Service ist.
    • Eine Liste mit einer oder mehreren API-Rollen, die mit dem Service verknüpft sind. Diesen Rollen wird „scp.pc.“ vorangestellt.

Das folgende JWT ist beispielsweise für die externe Abrechnungsanwendung von ACME vorgesehen. (Informationen, die für die Cloud-API-Autorisierung nicht relevant sind, wurden ausgelassen.)

{
    "sub": "acme_externalbillingapp",
    "cid": "acme_externalbillingapp",
    "scp": [
        "pc.service"
        "scp.pc.acme_externalbillingapp"
    ]
}

Beachten Sie die folgenden Punkte:

  • Basierend auf dem scp-Token-Claim erhält dieser Aufrufer Endpunktzugriff, wie in der Rolle „acme_externalbillingApp“ definiert. Aufgrund des pc.service-Eintrags verwendet dieser Aufrufer eine Ressourcenzugriffsstrategie, die Zugriff auf alle Ressourcen bietet.

Protokollierung

Für jeden Aufruf werden Informationen über den Aufrufer protokolliert. In der folgenden Tabelle sind die Felder aufgeführt, die Informationen darüber enthalten, wer der Aufrufer ist und woher der protokollierte Wert stammt.

Feld Wert
sub Der Wert des sub-Token-Claims aus dem JWT
clientId Der Wert des cid-Token-Claims aus dem JWT
user Eine leere Zeichenkette