Beispielablauf für eigenständige Services

Das folgende Diagramm veranschaulicht den Austausch von Authentifizierungs- und Autorisierungsinformationen für eigenständige Services. 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 vom Acme FNOLReporter ausgelöst.


Authentifizierungsablauf für eigenständige Services
  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), die API-Rolle der Anwendung (scp.cc.acme_fnolreporter), die Ressourcenzugriffsstrategie der Anwendung (cc.service) 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. Außerdem wird verifiziert, dass die API-Rolle und die Ressourcenzugriffsstrategie in der Anforderung mit den Angaben übereinstimmen, die bei der Registrierung des Services bei Guidewire Hub angegeben wurden.
  3. Guidewire Hub generiert ein JWT und sendet es an den Service. Dieses JWT enthält die Client-ID (cid) und einen scp-Token-Claim, der die API-Rolle (scp.cc.acme_fnolreporter), die Ressourcenzugriffsstrategie (cc.service) und zusätzliche Bereitstellungsinformationen enthält.
  4. Der Service sendet die API-Anforderung zusammen mit dem JWT an ClaimCenter.
  5. ClaimCenter bestimmt den Endpunktzugriff. Ausgehend vom Wert „scp.cc.“ der im JWT (scp.cc.acme_fnolreporter) enthalten ist, wird der Endpunktzugriff mithilfe der API-Rollendatei acme_fnolreporter.role.yaml definiert.
  6. Als Nächstes bestimmt ClaimCenter die Ressourcenzugriffsstrategie. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (cc.service) wird der Ressourcenzugriff laut Definition in der Datei serviceUser access.yaml gewährt. (* ClaimCenter beginnt mit serviceUser_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „serviceUser“ beginnen.)
  7. 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.service festgelegt. Das Plugin gibt somit den Proxy-Benutzer für Services zurück: serviceuser.
  8. ClaimCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der Proxy-Service-Benutzer: serviceuser.
    2. Der Endpunktzugriff wird durch die Datei acme_fnolreporter.role.yaml definiert.
    3. Der Ressourcenzugriff wird durch die Datei serviceUser access.yaml definiert. In der Basiskonfiguration werden alle Ressourcen durch die Dateien serviceuser access.yaml zur Verfügung gestellt. Daher gibt es logisch betrachtet keine Beschränkungen des Ressourcenzugriffs.
  9. ClaimCenter stellt die Antwort auf den ersten Aufruf bereit.