Übersicht über die Authentifizierung für Services mit Servicekontozuordnung

Endpunktzugriff für Services mit Servicekontozuordnung

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.

Bei einem Service-mit-Servicekontozuordnung-Aufruf ordnen die System-APIs den Service einem Servicekonto in der PolicyCenter-Datenbank zu. Anschließend fragt die PolicyCenter-Betriebsdatenbank nach den Benutzerrollen dieses Servicekontos ab. Der Service erhält Endpunktzugriff auf alle API-Rollen, deren Namen den Namen der Benutzerrollen des Servicekontos entsprechen.

Als Beispiel folgende Annahme: Der ACME QuoteAndBind-Service ist einem Servicekonto mit der Bezeichnung „acmeQuoteAndBind“ zugeordnet. Das Konto „acmeQuoteAndBind“ hat zwei Benutzerrollen: „ACME-Underwriter“ und „ACME-Rückversicherungsmanager“. Der ACME QuoteAndBind-Service löst einen System-API-Aufruf aus. PolicyCenter ordnet den Service dem Konto „acmeQuoteAndBind“ zu und fragt die Datenbank nach den Benutzerrollen des Servicekontos ab. Es werden zwei Benutzerrollen zurückgegeben: „ACME-Underwriter“ und „ACME-Rückversicherungsmanager“. PolicyCenter gewährt dem Service dann den Endpunktzugriff, der in den API-Rollen „ACME-Schadenregulierer“ und „ACME-Rückversicherungsmanager“ definiert ist.

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

Ressourcenzugriff für Services mit Servicekontozuordnung

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.

Der Ressourcenzugriff wird durch zwei Funktionen gesteuert: Ressourcenzugriffs-IDs und Ressourcenzugriffsstrategien.

Eine Ressourcenzugriffs-ID ist eine Zeichenfolge, die definiert, wer der Aufrufer ist oder was der Aufrufer besitzt. Ressourcenzugriffs-IDs werden verwendet, um zu bestimmen, auf welche Ressourcen ein authentifizierter Aufrufer über API-Aufrufe zugreifen kann.

• Eine Ressourcenzugriffs-ID kann identifizieren, wer der Aufrufer ist. Die Ressourcenzugriffs-ID für einen Serviceanbieter ist beispielsweise die Adressbuch-ID des Anbieters. In der Regel kann ein Serviceanbieter auf alle Schadenfälle zugreifen, die diese ID in der Liste der zugehörigen Kontakt-IDs enthalten.
• Eine Ressourcenzugriffs-ID kann identifizieren, was der Aufrufer besitzt. Die Ressourcenzugriffs-ID für einen Versicherungsnehmer ist beispielsweise eine Liste mit einer oder mehreren Policennummern. In der Regel kann ein Versicherungsnehmer auf alle Policen mit diesen Policennummern zugreifen.

Eine Ressourcenzugriffsstrategie ist ein Logiksatz, der die Bedeutung einer Ressourcenzugriffs-ID identifiziert. Die Basiskonfiguration umfasst die folgenden Ressourcenzugriffsstrategien für das Servicekonto:

Wenn ein Service einen Service-mit-Servicekontozuordnung-Aufruf ausführt, wird der Service einem Servicekontonamen zugeordnet. Dieser Kontoname wird als Ressourcenzugriffs-ID verwendet, und die Strategie pc_username wird verwendet. Diese Strategie besteht aus einer System-API-Logik, die den in den Zugriffssteuerungslisten (ACLs) der Basiskonfiguration definierten Benutzerzugriff so genau wie möglich abstimmt.

Weitere Informationen zum Verhalten des Ressourcenzugriffs finden Sie unter Ressourcenzugriff.

Proxy-Benutzerzugriff für Services mit Servicekontozuordnung

Für Services mit Servicekontozuordnung ist der Proxy-Benutzerzugriff nicht anwendbar. Das Servicekonto wird als der Benutzer für die Sitzung verwendet. Daher ist es nicht erforderlich, einen Proxy-Benutzer zuzuweisen, auch wenn der Anruf von einem Service kommt.

Servicekontozuordnung

Die Servicekontozuordnung ist ein Set von Name/Wert-Paaren, welche die Client-ID eines Services dem Namen eines Benutzers in der PolicyCenter-Datenbank zuordnen. Dieser Benutzer wird als das Servicekonto bezeichnet.

Wenn ein Serviceaufruf empfangen wird, prüft die Cloud-API, ob die Client-ID in der Servicekontozuordnung aufgeführt ist.

• Wenn die Client-ID gefunden wird, wird der Aufruf als Service-mit-Servicekontozuordnung-Aufruf behandelt. Das Servicekonto wird zum Sitzungsbenutzer, und der mit dem Servicekonto verknüpfte Zugriff definiert, was der Service tun kann.
• Wenn die Client-ID nicht gefunden wird, wird der Aufruf entweder als Service-mit-Benutzerkontext-Aufruf oder als eigenständiger Serviceaufruf behandelt.

Als Beispiel folgende Annahme: Die folgende Servicekontozuordnung ist vorhanden.

Angenommen, ein Aufruf wird von einem Service mit der Client-ID „0oaqt9pl1vZK1kybt0h7“ empfangen. Diese Client-ID ist in der Servicekontozuordnung vorhanden. Daher wird der Aufruf als ein Service-mit-Servicekontozuordnung-Aufruf behandelt. Der Aufruf ist mit dem Servicekonto mit dem Benutzernamen „acmeDocuments“ verknüpft.

Angenommen, ein Aufruf wird von einem Service mit der Client-ID „0oa33344455566677788“ empfangen. Diese Client-ID ist in der Servicekontozuordnung nicht vorhanden. Daher wird der Aufruf entweder als Service-mit-Benutzerkontext-Aufruf oder als eigenständiger Serviceaufruf behandelt.

Jeder Service hat eine einzige Client-ID. Daher werden für einen bestimmten Service entweder alle Aufrufe als Service-mit-Servicekontozuordnung-Aufruf behandelt, oder keiner der Aufrufe wird als Service-mit-Servicekontozuordnung-Aufruf behandelt. Wenn sich die Client-ID in der Servicekontozuordnung befindet, gilt die erste Annahme. Wenn nicht, gilt die zweite Annahme.

Speichern der Servicekontozuordnung

Die Servicekontozuordnung kann an unterschiedlichen Orten gespeichert werden. Für jeden Serviceaufruf prüft die Cloud-API alle Orte. Die Cloud-API verwendet die erste gefundene Zuordnung. Wenn also eine Client-ID an mehreren Stellen zugeordnet wird, wird nur die erste Zuordnung verwendet. Wenn eine Client-ID an keinem dieser Orte aufgeführt ist, behandelt die Cloud-API den Aufruf entweder als einen Service-mit-Benutzerkontext-Aufruf oder als einen eigenständigen Serviceaufruf.

Aus technischer Sicht können Servicekontozuordnungen auf alle diese Orte verteilt werden. Versicherer finden es jedoch möglicherweise einfacher, Servicekontozuordnungen zu verwalten, wenn nur ein Ort verwendet wird.

Speichern der Servicekontozuordnung: Guidewire Cloud Console

Cloud-API-Prüfungen finden an erster Stelle in den Konfigurationsvariablen der Guidewire Cloud Console (GCC) statt. Versicherer können diese Änderungen über die GCC-Benutzeroberfläche selbst vornehmen.

Servicezuordnungseinträge in GCC-Konfigurationsvariablen verwenden die folgende Syntax:

PLUGIN_AUTHENTICATIONVERIFIER_SUBJECTMAPPINGS_<sub>=<username>

Wobei gilt:

• <sub> ist der Wert des sub-Token-Claims des JWTs (der auf die Client-ID gesetzt ist).
• <username> ist der Benutzername des Servicekontos.

Um Änderungen an GCC-Konfigurationsvariablen bereitzustellen, müssen Sie den Server neu starten.

Speichern der Servicekontozuordnung: config.properties

Als Nächstes erfolgen die Cloud-API-Prüfungen der config.properties-Datei. Einträge in dieser Datei verwenden die folgende Syntax:

plugin.PLUGIN_AUTHENTICATIONVERIFIER_SUBJECTMAPPINGS_<sub>=<username>

Wobei gilt:

• <sub> ist der Wert des sub-Token-Claims des JWTs (der auf die Client-ID gesetzt ist).
• <username> ist der Benutzername des Servicekontos.

Um Änderungen an der Datei config.properties bereitzustellen, müssen Sie den Server neu starten.

Das Speichern der Servicekontozuordnung in config.properties kann in Entwicklungsinstanzen sinnvoll sein. Guidewire empfiehlt jedoch nicht, in Produktionsinstanzen die Servicekontozuordnung in config.properties zu speichern.

Das Servicekonto

Ein Servicekonto ist nur für die Verwendung durch einen einzelnen externen Service vorgesehen, der Cloud-API-Aufrufe durchführt. In der Regel gibt der Name des Servicekontos den Service wieder (z. B. acmeDocuments) und sieht nicht wie der Name eines Personenkontos aus (z. B. aapplegate).

Das Servicekonto muss über die für den Service erforderlichen Berechtigungen verfügen.

Guidewire empfiehlt, keine Servicekonten für Benutzeraktivitäten zu verwenden. Mit anderen Worten: Lassen Sie keine Benutzer sich mit einem Servicekonto in PolicyCenter anmelden.