Übersicht über die Authentifizierung externer Benutzer
Zur Authentifizierung gehören die Anmeldeinformationen und die Autorisierung. Die Authentifizierungsinformationen für externe Benutzer werden in JWTs angegeben und Informationen aus diesen JWTs werden in den Protokollen aufgezeichnet.
Anmeldeinformationen
Die Anmeldeinformationen eines externen Benutzers bestehen aus einem Benutzernamen und einem Kennwort. Die entsprechenden Informationen werden im IdP gespeichert.
Wenn ein Extern Benutzer einen API-Aufruf durchführt, sendet die aufrufende Anwendung die Anmeldeinformationen des Benutzers an Guidewire Hub. Guidewire Hub verknüpft diese Informationen mit dem jeweiligen IdP. Der IdP authentifiziert den Benutzer, indem bestätigt wird, dass das Kennwort richtig ist.
Weitere Informationen zum Konfigurieren des IdP finden Sie unter IdP konfigurieren.
Autorisierung
Endpunktzugriff für externe Benutzer
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.
Wenn ein externer Benutzer einen System-API-Aufruf durchführt, enthält der Aufruf ein JWT. Das JWT enthält eine Liste mit einer oder mehreren API-Rollen. Der Benutzer erhält Endpunktzugriff auf alle API-Rollen, deren Namen den im JWT aufgeführten Rollen entsprechen. Als Beispiel folgende Annahme: Ray Newton ist Versicherungsnehmer. Ray Newton löst einen System-API-Aufruf aus. Das JWT identifiziert die Rolle „Versicherter“. Ray Newton erhält den in der API-Rolle „Versicherter“ definierten Endpunktzugriff.Weitere Informationen zur Konfiguration von API-Rollen finden Sie unter Endpunktzugriff.
Ressourcenzugriff für externe Benutzer
Der Ressourcenzugriff definiert für einen bestimmten Ressourcentyp, auf welche Instanzen dieses Ressourcentyps 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 die Bedeutung einer Ressourcenzugriffs-ID identifiziert. Die Basiskonfiguration umfasst die folgenden Ressourcenzugriffsstrategien für externe Benutzer:
| Name der Strategie | Rolle, die diese Strategie verwendet | Für die Ressourcenzugriffs-ID wird angenommen... | Gewährt Zugriff auf... |
|---|---|---|---|
cc_policyNumbers |
Kontoinhaber und Versicherungsnehmer | Ein Array von Policennummern | Informationen, die mit beliebigen Schadenfällen im Zusammenhang mit einer der Policen verknüpft sind. |
cc_gwabuid |
Schadenfall-Serviceanbieter | Die ABUID (Address Book Unique IDentifier) des Serviceanbieterkontakts | Ressourcen, die mit Schadenfällen verknüpft sind, für die dieser Benutzer ein zugewiesener Serviceanbieter ist |
Wenn ein externer Benutzer einen System-API-Aufruf durchführt, sucht ClaimCenter nach einem Ressourcenzugriffs-Token-Claim.
- Wenn das Ressourcenzugriffs-Token
cc_policyNumberslautet, werden die Ressourcenzugriffs-IDs als Liste mit Policennummern behandelt. Der Benutzer erhält Zugriff auf alle Schadenfälle basierend auf einer dieser Policennummern. - Wenn das Ressourcenzugriffs-Token
cc_gwabuidist, wird die Ressourcenzugriffs-ID als Adressbuch-ID behandelt. Der Benutzer erhält Zugriff auf alle Schadenfälle, bei denen mindestens einer der Serviceanbieter über die ID verfügt.
Cloud-API erfordert, dass das JWT nicht mehr als ein Ressourcenzugriffsstrategie-Token hat.
- Wenn kein Ressourcenstrategie-Token vorhanden ist, wird dem Aufrufer die „Standard“-Ressourcenzugriffsstrategie zugewiesen. Diese Ressourcenstrategie gewährt nur Zugriff auf Metadatenendpunkte.
- Wenn mehrere Ressourcenstrategie-Token vorhanden sind, wird der Aufruf abgelehnt.
Weitere Informationen zum Verhalten des Ressourcenzugriffs finden Sie unter Ressourcenzugriff.
Proxy-Benutzerzugriff für externe Benutzer
Wenn ein Aufrufer einen System-API-Aufruf durchführt, kann die interne Logik von ClaimCenter Prüfungen auslösen, die in keinem Zusammenhang mit dem Endpunkt- oder Ressourcenzugriff stehen. Zum Beispiel:
- Ein Aufrufer kann versuchen, sich selbst eine Aktivität zuzuweisen. ClaimCenter muss prüfen, ob der Aufrufer über ausreichende Berechtigungen zum Besitz einer Aktivität verfügt.
- Ein Aufrufer kann beispielsweise versuchen, eine Zahlung über 2000 $ zu erstellen. ClaimCenter muss prüfen, ob der Betrag der Zahlung den Vollmachtsrahmen des Aufrufers übersteigt.
Externe Benutzer sind nicht in der ClaimCenter-Betriebsdatenbank aufgeführt und haben daher keine Systemberechtigungen oder Vollmachtsrahmen. Um diese Prüfungen auszuführen, verwenden die System-APIs Proxy-Benutzer. Ein Proxy-Benutzer ist ein interner Benutzer, der einem externen Benutzer oder Service zugewiesen wird, wenn ein externer Benutzer oder Service einen API-Aufruf auslöst. Wenn die interne Logik von ClaimCenter prüfen muss, ob der Aufrufer über ausreichenden Zugriff verfügt, wird der Proxy-Benutzer überprüft.
Weitere Informationen zum Verhalten des Proxy-Benutzerzugriffs finden Sie unter Proxy-Benutzerzugriff.
JWTs für externe Benutzer
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.
JWTs für externe Benutzer können die folgenden Token-Claims enthalten:
groups: Die API-Rollen, die dem externen Benutzer zugewiesen werden.- In diesem Token-Claim wird dem Gruppennamen das Präfix „
gwa.<planetclass>.<xc>.“ vorangestellt, wobei<planetclass>entweder auf „prod“, „preprod“ oder „lower“ gesetzt ist und wobei <xc> der Anwendungscode (z. B. „cc“ oder „pc“) ist.
- In diesem Token-Claim wird dem Gruppennamen das Präfix „
scp: Die Ressourcenzugriffsstrategie, die auf die Ressourcenzugriffs-IDs angewendet werden sollcc_policyNumbers: Die Ressourcenzugriffs-IDs (wennscpcc_policyNumbersenthältenthält)cc_gwabuid: Die Ressourcenzugriffs-IDs (wennscpcc_gwabuidenthält)
Das folgende JWT ist beispielsweise für einen externen Benutzer gedacht, der Versicherungsnehmer mit zwei Policen ist: 54-123456 und 54-273411. (Informationen, die für die System-API-Autorisierung nicht relevant sind, wurden ausgelassen.)
{
"groups" : [
"gwa.prod.cc.Insured"
],
"scp": [
"cc_policyNumbers"
],
"cc_policyNumbers": [
"54-123456",
"54-273411"
]
}
Beachten Sie die folgenden Punkte:
- Basierend auf dem
groups-Token-Claim erhält dieser Aufrufer Endpunktzugriff, wie in der Rolle „Versicherter“ definiert. - Basierend auf dem
SCP-Token-Claim werden die Ressourcenzugriffs-IDs dieses Aufrufers als Policennummern interpretiert. - Basierend auf dem
cc_policyNumbers-Token-Claim hat dieser Aufrufer Zugriff auf Informationen zu Schadenfällen in der Police 54-123456 oder in der Police 54-273411.
Als zweites Beispiel gilt das folgende JWT für einen externen Benutzer, der ein Anbieter ist. Die eindeutige ID des Guidewire-Adressbuchs des Anbieters lautet cc:demo_4532. (Informationen, die für die System-API-Autorisierung nicht relevant sind, wurden ausgelassen.)
{
"groups" : [
"gwa.prod.cc.ServiceRequestSpecialist"
],
"scp": [
"cc_gwabuid"
],
"cc_gwabuid": [
"cc:demo_4532"
]
}
Beachten Sie die folgenden Punkte:
- Basierend auf dem
groups-Token-Claim erhält dieser Aufrufer Endpunktzugriff, wie in der Rolle „ServiceRequestSpecialist“ definiert. - Basierend auf dem
scp-Token-Claim werden die Ressourcenzugriffs-IDs dieses Aufrufers als eindeutige ID im Guidewire-Adressbuch interpretiert. - Basierend auf dem
cc_gwabuid-Token-Claim hat dieser Aufrufer Zugriff auf Informationen zu Schadenfällen, bei denen einer der Serviceanbieter ein Kontakt mit der ID cc:demo_4532 ist.
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 |
Der Benutzername des externen Benutzers |