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 (pc.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.pc.Account_Holder) und dessen Ressourcenzugriffs-IDs bereit. Für Ray ist dies eine Liste seiner Kontonummern (464778619).
  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 (pc_accountNumbers) und zusätzliche Bereitstellungsinformationen festlegt, ein groups-Token, das die Gruppen des Benutzers festlegt (gwa.prod.pc.Account_Holder), und ein pc_accountNumbers-Token, das die Ressourcenzugriffs-IDs des Benutzers festlegt (464778619).
  5. Die aufrufende Anwendung sendet die API-Anforderung zusammen mit dem JWT an PolicyCenter.
  6. PolicyCenter bestimmt den Endpunktzugriff. Ausgehend von den im JWT enthaltenen Gruppen (gwa.prod.pc.Account_Holder) wird der Endpunktzugriff mithilfe der API-Rollendatei Account_Holder.role.yaml definiert.
  7. Als Nächstes bestimmt PolicyCenter die Ressourcenzugriffsstrategie. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (pc_accountNumbers) wird der Ressourcenzugriff laut Definition in der Datei accountholder access.yaml gewährt. (* PolicyCenter beginnt mit accountholder_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „accountholder“ beginnen.)
  8. Um zu bestimmen, welcher Proxy-Benutzer der Sitzung zugewiesen werden soll, greift PolicyCenter auf das RestAuthenticationSourceCreator-Plugin zu. Das JWT hat eine Ressourcenzugriffsstrategie für pc_accountNumbers festgelegt. Das Plugin gibt somit den Proxy-Benutzer für externe Benutzer zurück: extuser.
  9. PolicyCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der externe Proxy-Benutzer: extuser.
    2. Der Endpunktzugriff wird durch die Datei Account_Holder.role.yaml definiert.
    3. Der Ressourcenzugriff wird durch die accountholder access.yaml-Datei mit der Ressourcenzugriffs-ID 464778619 definiert.
  10. PolicyCenter stellt die Antwort auf den ersten Aufruf bereit.