Beispielablauf für externe Benutzer

Das folgende Diagramm veranschaulicht den Austausch von Authentifizierungs- und Autorisierungsinformationen für externe Benutzer. Die Farben stehen für Folgendes:

  • Orange: Anmeldeinformationen
  • Blau: Endpunktzugriffsinformationen
  • Grün: Ressourcenzugriffsinformationen
  • Rot: Proxy-Benutzer- und Sitzungsinformationen

Einige Werte werden verwendet, um mehrere Zugriffsarten zu bestimmen. Diese Werte erscheinen zunächst in schwarz (wenn sie nicht für einen speziellen Zugriffstyp gelten) und dann später in einer oder mehreren bestimmten Farben (als Identifizierung des Werts, der zu diesem Zeitpunkt im Prozess für eine bestimmte Zugriffsart verwendet wird).

Im folgenden Beispiel wird ein API-Aufruf von Ray Newton ausgelöst, einem externen Benutzer, der eine browserbasierte Anwendung verwendet.


Authentifizierungsablauf für externe Benutzer
  1. Wenn Ray einen API-Aufruf auslöst, muss die aufrufende Anwendung zuerst einen JWT vom Guidewire Hub anfordern. Um den Prozess zum Abrufen des JWT einzuleiten, sendet die aufrufende Anwendung ihre Client-ID (00ubx7m33sHP1tsew7b4), die ID des IdP (acmeIdP_ID), die Ressourcenzugriffsstrategie der Anwendung (cc.username) und zusätzliche Bereitstellungsinformationen (tenant.acme, project.default, planet_class.prod).
  2. Um den Benutzer zu authentifizieren, erfasst Guidewire Hub den Benutzernamen (rnewton@email.com) und das Kennwort (aPassword) des Benutzers über ein Anmeldefenster. Diese Informationen werden an den zuständigen IdP übermittelt. Der IdP authentifiziert den Benutzer und stellt eine SAML-Antwort mit dem Namen des Benutzers (rnewton@email.com), den Gruppen des Benutzers (gwa.prod.cc.Insured) und dessen Ressourcenzugriffs-IDs bereit. Für Ray ist dies eine Liste seiner Policennummern (PA-123456).
  3. Guidewire Hub sendet einen Code an die aufrufende Anwendung. Die aufrufende Anwendung verwendet diesen Code, um einen JWT anzufordern.
  4. Guidewire Hub generiert einen JWT und sendet ihn an die aufrufende Anwendung. Dieses JWT enthält die Client-ID (cid), einen scp-Token-Claim, der die Ressourcenzugriffsstrategie (cc_policyNumbers) und zusätzliche Bereitstellungsinformationen enthält, ein groups-Token, das die Gruppen des Benutzers benennt (gwa.prod.cc.Insured), und ein cc_policyNumbers-Token, das die Ressourcenzugriffs-IDs des Benutzers enthält (PA-123456).
  5. Die aufrufende Anwendung sendet die API-Anforderung zusammen mit dem JWT an ClaimCenter.
  6. ClaimCenter bestimmt den Endpunktzugriff. Ausgehend von den im JWT enthaltenen Gruppen (gwa.prod.cc.Insured) wird der Endpunktzugriff mithilfe der API-Rollendatei Insured.role.yaml definiert.
  7. Als Nächstes bestimmt ClaimCenter die Ressourcenzugriffsstrategie. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (cc_policyNumbers) wird der Ressourcenzugriff laut Definition in den Dateien policyNumbers access.yaml gestattet. (* ClaimCenter beginnt mit policyNumbers_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „policyNumbers“ beginnen.)
  8. Um zu bestimmen, welcher Proxy-Benutzer der Sitzung zugewiesen werden soll, greift ClaimCenter auf das RestAuthenticationSourceCreator-Plugin zu. Das JWT hat eine Ressourcenzugriffsstrategie mit dem Namen cc_policyNumbers festgelegt. Das Plugin gibt somit den Proxy-Benutzer für externe Benutzer zurück: extuser.
  9. ClaimCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der externe Proxy-Benutzer: extuser.
    2. Der Endpunktzugriff wird durch die Datei Insured.role.yaml definiert.
    3. Der Ressourcenzugriff wird durch die policyNumbers access.yaml-Datei mit der Ressourcenzugriffs-ID PA-123456 definiert.
  10. ClaimCenter stellt die Antwort auf den ersten Aufruf bereit.