Beispielablauf für interne Benutzer

Das folgende Diagramm veranschaulicht den Austausch von Authentifizierungs- und Autorisierungsinformationen für interne 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 Andy Applegate ausgelöst, einem internen Benutzer, der eine browserbasierte Anwendung verwendet.


Authentifizierungsablauf für interne Benutzer
  1. Wenn Andy 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 (aapplegate@acme.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 bereit (aapplegate@acme.com).
  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_username) und zusätzliche Bereitstellungsinformationen festlegt, und ein cc_username-Token, das die Ressourcenzugriffs-IDs des Benutzers enthält (aapplegate@acme.com).
  5. Die aufrufende Anwendung sendet die API-Anforderung zusammen mit dem JWT an ClaimCenter.
  6. ClaimCenter bestimmt den Endpunktzugriff.
    1. Mit dem Benutzernamen im JWT (aapplegate@acme.com) fragt ClaimCenter die Benutzerrollen ab, die dieser Benutzer hat. Eine Rolle wird zurückgegeben: Adjuster.
    2. Basierend auf der zurückgegebenen Rolle wird die Adjuster.role.yaml-API-Rollendatei verwendet, um den Endpunktzugriff zu definieren.
  7. Als Nächstes bestimmt ClaimCenter die Ressourcenzugriffsstrategie. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (cc_username) wird der Ressourcenzugriff laut Definition in den internal access.yaml-Dateien gestattet. (* ClaimCenter beginnt mit internal_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „internal“ beginnen.)
  8. Der Proxy-Benutzerzugriff ist für interne Benutzer nicht relevant.
  9. ClaimCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der interne Benutzer: aapplegate@acme.com.
    2. Der Endpunktzugriff wird durch die Datei Adjuster.role.yaml definiert.
    3. Der Ressourcenzugriff wird durch die internal access.yaml-Datei mit der Ressourcenzugriffs-ID aapplegate@acme.com definiert.
  10. ClaimCenter stellt die Antwort auf den ersten Aufruf bereit.