Übersicht über die Authentifizierung interner Benutzer

Zur Authentifizierung gehören die Anmeldeinformationen und die Autorisierung. Die Authentifizierungsinformationen für interne Benutzer (per Bearer-Token Authentifizierung) werden in JWTs angegeben und Informationen aus diesen JWTs werden in den Protokollen aufgezeichnet.

Anmeldeinformationen

Die Anmeldeinformationen eines internen Benutzers bestehen aus einem Benutzernamen und einem Kennwort. Die entsprechenden Informationen werden im IdP gespeichert.

Wenn ein interner 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 interne 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 interner Benutzer einen System-API-Aufruf durchführt (entweder über die Standardauthentifizierung oder die Authentifizierung mit dem Bearer-Token), fragt ClaimCenter die Betriebsdatenbank nach den Benutzerrollen dieses internen Benutzers ab. Der Benutzer erhält Endpunktzugriff auf alle API-Rollen, deren Namen den Namen der Benutzerrollen des Benutzers entsprechen.

Als Beispiel folgende Annahme: Andy Applegate ist ein interner Benutzer mit zwei Benutzerrollen: Schadenregulierer und Rückversicherungsmanager. Andy Applegate löst einen System-API-Aufruf aus. Wenn der API-Aufruf empfangen wird, fragt ClaimCenter die Datenbank nach Andys Benutzerrollen ab. Es werden zwei Benutzerrollen zurückgegeben: Schadenregulierer und Rückversicherungsmanager. ClaimCenter gewährt dann Andy den in den API-Rollen „Schadenregulierer“ und „Rückversicherungsmanager“ definierten Endpunktzugriff.

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

Ressourcenzugriff für interne 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 interne Benutzer:

Name der Strategie Rolle, die diese Strategie verwendet Für die Ressourcenzugriffs-ID wird angenommen... Gewährt Zugriff auf...
cc_username Interne Benutzer Ein ClaimCenter-Benutzername Alle Informationen, die dieser interne Benutzer in ClaimCenter basierend auf den zugehörigen Zugriffssteuerungslisten (ACLs) sehen kann.

Wenn ein interner Benutzer einen System-API-Aufruf durchführt, wird der Benutzername als Ressourcenzugriffs-JWT verwendet. Der Benutzername wird als Ressourcenzugriffs-ID verwendet. Die Strategie cc_username oder pc_username wird automatisch 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 interne Benutzer

Der Proxy-Benutzerzugriff ist für interne Benutzer nicht anwendbar.

JWTs für interne 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 interne Benutzer können die folgenden Token-Claims enthalten:

  • scp: Die Ressourcenzugriffsstrategie, die auf die Ressourcenzugriffs-ID angewendet werden soll. (Für interne Benutzer ist dies auf cc_username gesetzt.)
  • cc_username: Die Ressourcenzugriffs-ID. (Dies ist der Benutzername des Benutzers)

Das folgende JWT gilt beispielsweise für einen internen Benutzer mit dem Benutzernamen aapplegate. (Informationen, die für die System-API-Autorisierung nicht relevant sind, wurden ausgelassen.)

{
    "scp": [
        "cc_username"
    ],
    "cc_username": "aapplegate"
}

Beachten Sie die folgenden Punkte:

  • Basierend auf dem scp-Token-Claim wird die Ressourcenzugriffs-ID dieses Aufrufers als Benutzername interpretiert.
  • Basierend auf dem cc_username-Token-Claim hat dieser Aufrufer Zugriff auf Informationen, die sich darauf beziehen, auf was der Benutzer aapplegate zugreifen kann.

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 internen Benutzers