Beispielablauf für Services mit Servicekontozuordnung

Das folgende Diagramm veranschaulicht den Austausch von Authentifizierungs- und Autorisierungsinformationen für Services mit Servicekontozuordnung. 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 der Acme-Abrechnungsanwendung BillingApp ausgelöst.


Authentifizierungsablauf für Services mit Servicekontozuordnung
  1. Wenn FNOLReporter einen API-Aufruf auslöst, muss zuerst ein JWT vom Guidewire Hub angefordert werden. Die Anforderung des JWT umfasst die Client-ID (0oaqt9pl1vZK1kybt0h7), das Geheimnis (aSecret) und zusätzliche Bereitstellungsinformationen (tenant.acme, project.default, planet_class.prod).
  2. Guidewire Hub authentifiziert die Services basierend auf der Client-ID und dem Geheimnis.
  3. Guidewire Hub generiert ein JWT und sendet es an den Service. Dieses JWT enthält die Client-ID (cid) und zusätzliche Bereitstellungsinformationen.
  4. Der Service sendet die API-Anforderung zusammen mit dem JWT an PolicyCenter.
  5. PolicyCenter bestimmt den Endpunktzugriff.
    1. Zuerst führt PolicyCenter eine Suche durch, um die Client-ID (0oaqt9pl1vZK1kybt0h7) einem Servicekontonamen (acmebillingappuser) zuzuordnen.
    2. Danach fragt PolicyCenter die Benutzerrollen ab, die dieser Kontoname hat. Eine Rolle wird zurückgegeben: acme_billingapp.
    3. Basierend auf der zurückgegebenen Rolle wird die acme_billingapp.role.yaml-API-Rollendatei verwendet, um den Endpunktzugriff zu definieren.
  6. Als Nächstes bestimmt PolicyCenter die Ressourcenzugriffsstrategie. Basierend auf der Tatsache, dass ein gültiges Servicekonto gefunden wurde, gewährt PolicyCenter den Ressourcenzugriff wie in den internal access.yaml-Dateien definiert. (* PolicyCenter beginnt mit internal_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „internal“ beginnen.)
  7. Für Services mit Servicekontozuordnung ist der Proxy-Benutzerzugriff nicht relevant.
  8. PolicyCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist das Servicekonto: acmebillingappuser.
    2. Der Endpunktzugriff wird durch die Datei acme_billingapp.role.yaml definiert.
    3. Der Ressourcenzugriff wird durch die internal access.yaml-Datei mit der Ressourcenzugriffs-ID acmebillingappuser definiert.
  9. PolicyCenter stellt die Antwort auf den ersten Aufruf bereit.