Beispielablauf für Services mit Benutzerkontext

Das folgende Diagramm veranschaulicht den Austausch von Authentifizierungs- und Autorisierungsinformationen für Services mit Benutzerkontext. 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).

Services mit Benutzerkontext: interne Benutzer

Im folgenden Beispiel wird ein API-Aufruf von der Acme-Policenabrechnungsanwendung BillingApp im Namen von Andy Applegate ausgelöst, der ein externer Benutzer ist.


Authentifizierungsablauf für Services im Zusammenhang mit internen Benutzern
  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), die Tatsache, dass der Aufruf für einen Benutzer (cc.allowusercontext) erfolgt, 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), den Wert cc.allowusercontext (der angibt, dass Benutzerinformationen in einem zusätzlichen Benutzerkontext-Header angegeben sind) und zusätzliche Bereitstellungsinformationen enthält.
  4. Der Service sendet die API-Anforderung zusammen mit dem JWT und einem Benutzerkontext-Header, der den Benutzer (aapplegate@acme.com), die Ressourcenzugriffsstrategie des Benutzers (cc_username) und die Ressourcenzugriffs-ID (aapplegate@acme.com) angibt, an ClaimCenter.
  5. ClaimCenter muss den Endpunktzugriff sowohl auf der Serviceebene als auch auf der Benutzerebene bestimmen. Der Vorgang beginnt auf der Serviceebene. Ausgehend vom API-Rollenwert im JWT (scp.cc.acme_fnolreporter) wird der Zugriff auf der Serviceebene mithilfe der API-Rollendatei acme_fnolreporter.role.yaml definiert.
  6. Als Nächstes bestimmt ClaimCenter den Endpunktzugriff auf der Benutzerebene.
    1. Mit dem Benutzernamen im Benutzerkontext-Header (aapplegate@acme.com) fragt ClaimCenter die Benutzerrollen ab, die dieser Benutzer hat. Eine Rolle wird zurückgegeben: Adjuster.
    2. Ausgehend von der zurückgegebenen Rolle wird die Adjuster.role.yaml-API-Rollendatei verwendet, um den Zugriff auf der Benutzerebene zu definieren.
  7. ClaimCenter muss auch den Ressourcenzugriff sowohl auf der Serviceebene als auch auf der Benutzerebene bestimmen. Der Vorgang beginnt mit der Ressourcenzugriffsstrategie auf der Serviceebene. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (cc.service) wird der Ressourcenzugriff auf der Serviceebene 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.)
  8. ClaimCenter bestimmt die Ressourcenzugriffsstrategie auf der Benutzerebene. Ausgehend vom Wert der Ressourcenzugriffsstrategie im Benutzerkontext-Header (cc_username) wird der Ressourcenzugriff auf Benutzerebene 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.)
  9. Proxy-Benutzerzugriff ist für Services mit Benutzerkontext nicht relevant, wenn der Benutzer ein interner Benutzer ist.
  10. ClaimCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der interne Benutzer: aapplegate@acme.com.
    2. Der Endpunktzugriff ist die Schnittmenge der auf der Serviceebene (acme_fnolreporter.role.yaml) und auf der Benutzerebene (Adjuster.role.yaml) definierten Endpunkte und Operationen. Endpunkte, Operationen und Felder müssen auf beiden Ebenen enthalten sein, damit sie für den Aufruf verfügbar sind.
    3. Der Ressourcenzugriff ist die Schnittmenge zwischen den Ressourcen, auf die der Service zugreift (wie in serviceUser access.yaml definiert) und den Ressourcen, die dem Benutzer zur Verfügung stehen (wie in internal access.yaml mit der Ressourcenzugriffs-ID von aapplegate@acme.com definiert). In der Basiskonfiguration werden alle Ressourcen durch die Dateien serviceuser access.yaml zur Verfügung gestellt. Daher gibt der Ressourcenzugriff auf der Serviceebene logisch betrachtet keine Einschränkungen an. Der Aufruf kann auf jede Ressource zugreifen, sofern sie über den Ressourcenzugriff auf der Benutzerebene verfügbar ist.
  11. ClaimCenter stellt die Antwort auf den ersten Aufruf bereit.

Services mit Benutzerkontext: externe Benutzer

Im folgenden Beispiel wird ein API-Aufruf vom Acme FNOLReporter im Namen von Ray Newton ausgelöst, der ein externer Benutzer ist.


Authentifizierungsablauf für Services im Zusammenhang mit externen Benutzern
  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), die Tatsache, dass der Aufruf für einen Benutzer (cc.allowusercontext) erfolgt, 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), den Wert cc.allowusercontext (der angibt, dass Benutzerinformationen in einem zusätzlichen Benutzerkontext-Header angegeben sind) und zusätzliche Bereitstellungsinformationen enthält.
  4. Der Service sendet die API-Anforderung zusammen mit dem JWT und einem Benutzerkontext-Header, der den Benutzer (rnewton@email.com), die Ressourcenzugriffsstrategie des Benutzers (cc_policyNumbers) und die Ressourcenzugriffs-ID (PA-123456) angibt, an ClaimCenter.
  5. ClaimCenter muss den Endpunktzugriff sowohl auf der Serviceebene als auch auf der Benutzerebene bestimmen. Der Vorgang beginnt auf der Serviceebene. Ausgehend vom API-Rollenwert im JWT (scp.cc.acme_fnolreporter) wird der Zugriff auf der Serviceebene mithilfe der API-Rollendatei acme_fnolreporter.role.yaml definiert.
  6. Als Nächstes bestimmt ClaimCenter den Endpunktzugriff auf der Benutzerebene. Ausgehend vom Inhalt des groups-Token-Claims im Benutzerkontext-Header (gwa.prod.cc.Insured) wird der Zugriff auf der Benutzerebene mithilfe der API-Rollendatei Insured.role.yaml definiert.
  7. ClaimCenter muss auch den Ressourcenzugriff sowohl auf der Serviceebene als auch auf der Benutzerebene bestimmen. Der Vorgang beginnt mit der Ressourcenzugriffsstrategie auf der Serviceebene. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (cc.service) gewährt ClaimCenter den Ressourcenzugriff auf der Serviceebene laut Definition in der Datei serviceUser access.yaml. (* ClaimCenter beginnt mit serviceUser_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „serviceUser“ beginnen.)
  8. Als Nächstes bestimmt ClaimCenter die Ressourcenzugriffsstrategie auf der Benutzerebene. Ausgehend vom Wert der Ressourcenzugriffsstrategie im Benutzerkontext-Header (cc_policyNumbers), wird der Ressourcenzugriff auf der Benutzerebene laut Definition in den policyNumbers access.yaml-Dateien 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.)
  9. Um zu bestimmen, welcher Proxy-Benutzer der Sitzung zugewiesen werden soll, greift ClaimCenter auf das RestAuthenticationSourceCreator-Plugin zu. Der Benutzerkontext-Header hat eine Ressourcenzugriffsstrategie mit dem Namen cc_policyNumbers festgelegt. Das Plugin gibt somit den Proxy-Benutzer für externe Benutzer zurück: extuser.
  10. ClaimCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der externe Proxy-Benutzer: extuser.
    2. Der Endpunktzugriff ist die Schnittmenge der auf der Serviceebene (acme_fnolreporter.role.yaml) und auf der Benutzerebene (Insured.role.yaml) definierten Endpunkte und Operationen. Endpunkte, Operationen und Felder müssen auf beiden Ebenen enthalten sein, damit sie für den Aufruf verfügbar sind.
    3. Der Ressourcenzugriff ist die Schnittmenge zwischen den Ressourcen, auf die der Service zugreift (wie in serviceUser access.yaml definiert) und den Ressourcen, die dem Benutzer zur Verfügung stehen (wie in policyNumbers access.yaml mit der Ressourcenzugriffs-ID von PA-123456 definiert). In der Basiskonfiguration werden alle Ressourcen durch die Dateien serviceUser access.yaml zur Verfügung gestellt. Daher gibt der Ressourcenzugriff auf der Serviceebene logisch betrachtet keine Einschränkungen an. Der Aufruf kann auf jede Ressource zugreifen, sofern sie über den Ressourcenzugriff auf der Benutzerebene verfügbar ist.
  11. ClaimCenter stellt die Antwort auf den ersten Aufruf bereit.