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

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.

Wenn sich ein Service im Benutzerkontext authentifiziert, stellt er Informationen über einen Benutzer bereit. Auf Benutzerebene gibt es jedoch keine Authentifizierung. Die Authentifizierung erfolgt nur auf der Service-Ebene.

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 Services mit Benutzerkontext

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 verfügbar sind, wenn System-API-Aufrufe ausgelöst werden. 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-Benutzer-Kontext-Aufruf prüfen die System-APIs zwei Sätze von API-Rollen:

  • Die dem Service zugewiesenen API-Rollen
  • Die dem Benutzer zugewiesenen API-Rollen

Der dem Aufruf gewährte Endpunktzugriff ist der Schnittpunkt des durch diese beiden Sätze gewährten Endpunktzugriffs. Mit anderen Worten: Um auf einen Endpunkt, eine Operation oder ein Feld zugreifen zu können, muss der Zugriff mindestens einer API-Rolle gewährt werden, die dem Service zugewiesen ist, und mindestens einer API-Rolle, die dem Benutzerkonto zugewiesen ist.

Als Beispiel folgende Annahme: Der externe Dokumentenmanagerservice von ACME hat die folgende API-Rolle mit folgendem Endpunktzugriff:

  • acme_externaldocumentmanager
    • GET /documents
    • POST /documents

Und nehmen wir an, Ray Newton hat die folgende API-Rolle mit folgendem Endpunktzugriff:

  • Versicherter
    • GET /documents
    • GET /coverages

Angenommen, der externe Dokumentenmanagerservice von ACME ruft einen Service mit einem Benutzerkonto auf, welches das Benutzerkonto von Ray Newton verwendet. Der Aufruf hätte Zugriff auf GET /documents, da dieser Endpunkt sowohl dem Service als auch dem Benutzerkonto zugewiesen wurde. Der Aufruf hätte keinen Zugriff auf POST /documents oder GET /coverages, da keiner dieser Endpunkte sowohl dem Service als auch dem Benutzerkonto gewährt wurde.

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

Ressourcenzugriff für Services mit Benutzerkontext

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 Benutzer und Services.

  • Ressourcenzugriffsstrategien für Benutzer beschränken den Aufrufer in der Regel auf Objekte, die dem Benutzer gehören. Beispielsweise kann ein Kontoinhaber Objekte anzeigen, die (direkt oder indirekt) dem Konto angehören.
  • Ressourcenzugriffsstrategien für Services schränken den Aufrufer in der Regel in keiner Weise ein.

Ähnlich dem Endpunktzugriff ist der Ressourcenzugriff für einen Service-mit-Benutzerkontext-Aufruf der Schnittpunkt des Ressourcenzugriffs für den Service und des Ressourcenzugriffs für den Benutzer. In der Basiskonfiguration haben Services Zugriff auf alle Ressourcen. Daher entspricht der Ressourcenzugriff für einen Service-mit-Benutzerkontext-Aufruf logisch dem Ressourcenzugriff für den Benutzer.

Als Beispiel folgende Annahme: Der externe Dokumentenmanagerservice von ACME hat Zugriff auf die folgenden Dokumente:

  • (alle Dokumente)

Und nehmen wir an, Ray Newton hat Zugriff auf die folgenden Dokumente:

  • Mit Police 55-123456 verknüpfte Dokumente
    • Dokument xc:127
    • Dokument xc:356
  • Direkt mit Konto C000324667 verknüpfte Dokumente
    • Dokument xc:888

Wenn der externe Dokumentenmanagerservice von ACME einen Service-mit-Benutzerkonto-Aufruf für Ray Newton ausführt, hat der Aufruf Zugriff auf die Dokumente xc:127, xc:356 und xc:888, da sowohl der Service als auch der Benutzer auf diese Ressourcen zugreifen können. Der Aufruf hätte keinen Zugriff auf andere Dokumente, da es keine anderen Dokumente gibt, auf die sowohl der Service als auch der Benutzer Zugriff haben.

Weitere Informationen zum Verhalten des Ressourcenzugriffs finden Sie unter Ressourcenzugriff.

Proxy-Benutzerzugriff für Services mit Benutzerkontext

Jeder Cloud-API-Aufruf erfolgt im Kontext einer Sitzung. Ein in der ClaimCenter Datenbank aufgeführter Benutzer muss an diese Sitzung angehängt werden. ClaimCenter 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.

Wenn ein Service einen Aufruf mit einem Benutzerkontext durchführt, kann der zugehörige Benutzer ein interner Benutzer sein. Ein interner Benutzer ist eine Person, die in der ClaimCenter-Betriebsdatenbank als Benutzer aufgeführt ist. In diesem Fall wird dieser interne Benutzer als der Sitzungsbenutzer verwendet.

Wenn ein Service einen Aufruf mit einem Benutzerkontext durchführt, kann der zugehörige Benutzer ein externer Benutzer sein. Ein externer Benutzer ist eine Person, die dem Versicherer bekannt, aber nicht als Benutzer in der ClaimCenter-Betriebsdatenbank aufgeführt ist. Dies kann beispielsweise ein Versicherungsnehmer, ein Anbieter oder ein Kontoinhaber sein. Wenn der Benutzerkontext einen externen Benutzer angibt, muss der Sitzung ein Proxy-Benutzer zugewiesen werden.

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 externe Proxy-Benutzer, wird für Aufrufe verwendet, die entweder von externen Benutzern oder von Services mit Benutzerkontext durchgeführt werden, wobei der Benutzerkontext einen externen Benutzer angibt.

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

JWTs für Services mit Benutzerkontext

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 Aufruf mit Benutzerkontext 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 Service-für-Benutzerkontext-Aufruf aufgeführt, die sich auf die Cloud-API-Authentifizierung beziehen.

"sub": "<clientId>",
"cid": "<clientId>", 
"scp": [
  "cc.service",
  "scp.cc.<serviceAPIRole>",
  "cc.allowusercontext"
]
  • 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 cc.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.cc.“ vorangestellt.
    • Den cc.allowusercontext-Wert, mit dem der Aufruf zusätzlichen Benutzerkontext in der Kopfzeile angeben kann. (Wenn der Header einen GW-User-Context-Header enthält, wird dieser als Service-mit-Benutzerkontext-Aufruf und nicht als eigenständiger Serviceaufruf behandelt).

Der Wert cc.allowusercontext gibt an, dass der Aufruf auch einen Benutzerkontext präsentiert. Informationen zum Benutzer werden in einem GW-User-Context-Header angegeben. Für interne Benutzer müssen im Header der Benutzername, die Ressourcenzugriffsstrategie und die Ressourcenzugriffs-ID angegeben werden. Für externe Benutzer müssen im Header der Benutzername, die Benutzerrollen sowie die Ressourcenzugriffsstrategie und Ressourcenzugriffs-IDs angegeben werden. Der Header muss base64-codiert sein.

Der Header muss ein JSON-Nutzdatenpaket sein, das wie in den folgenden Absätzen beschrieben formatiert ist.

Für einen internen Benutzer lautet die Syntax des GW-User-Context-Headers:

{
  "sub": "<userName>",
  "cc_username" : "<userName>"
}

Beachten Sie die folgenden Punkte:

  • Der Benutzername ist im sub-Token-Claim angegeben.
  • Die Ressourcenzugriffsstrategie wird durch das Vorhandensein des cc_username-Token-Claims angegeben.
  • Die Ressourcenzugriffs-ID ist der Benutzername, der im cc_username-Token-Claim angegeben ist.

Für einen externen Benutzer, der ein Versicherungsnehmer ist, lautet die Syntax des GW-User-Context-Headers:

{
  "sub": "<userName>",
  "groups": [
    "<userAPIroleList>"
  ],
  "cc_policyNumbers" : [
    "<policyNumbers>"
  ]
}

Beachten Sie die folgenden Punkte:

  • Der Benutzername ist im sub-Token-Claim angegeben. (Wird für die Protokollierung verwendet, hat aber sonst keine funktionalen Auswirkungen.)
  • Die API-Rollen des Benutzers sind im groups-Token-Claim aufgeführt. Jedem Rollennamen muss das Präfix „gwa.<planet_class>.cc“ vorangestellt werden.
  • Die Ressourcenzugriffsstrategie wird durch das Vorhandensein des cc_policyNumbers-Token-Claims angegeben.
  • Die Ressourcenzugriffs-IDs sind eine Liste von Policennummern, die im cc_policyNumbers-Token-Claim angegeben sind.

Für einen externen Benutzer, der ein Serviceanbieter ist (auch als Anbieter bezeichnet), lautet die Syntax des GW-User-Context-Headers:

{
  "sub": "<userName>",
  "groups": [
    "<userAPIroleList>"
  ],
  "cc_gwabuid" : "<addressBookUniqueIdentifier>"
}

Beachten Sie die folgenden Punkte:

  • Der Benutzername ist im sub-Token-Claim angegeben. (Wird für die Protokollierung verwendet, hat aber sonst keine funktionalen Auswirkungen.)
  • Die API-Rollen des Benutzers sind im groups-Token-Claim aufgeführt. Jedem Rollennamen muss das Präfix „gwa.<planet_class>.cc“ vorangestellt werden.
  • Die Ressourcenzugriffsstrategie wird durch das Vorhandensein des cc_gwabuid-Token-Claims angegeben.
  • Die Ressourcenzugriffs-ID ist ein GuideWire Address Book Unique Identifier, der im Token-Claim cc_gwabuid angegeben ist.
Anmerkung: Wenn ein Aufruf einen JWT mit dem cc.allowusercontext-Token-Claim enthält, der Header des Anforderungsobjekts jedoch keinen Benutzerkontext-Header enthält, behandelt die Cloud-API den Aufruf so, als käme er von einem eigenständigen Service. Mit anderen Worten wird der Aufruf auf den Zugang beschränkt, gewährt wird. Es werden keine benutzerbasierten Einschränkungen angewendet, da kein Benutzerkontext-Header vorhanden war, der einen Benutzer angibt.

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

Wenn der Benutzer im Benutzerkontext ein interner Benutzer ist, der Benutzername des internen Benutzers.

Wenn der Benutzer im Benutzerkontext ein externer Benutzer ist, der sub-Wert aus dem Benutzerkontext.