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 Alice Applegate ausgelöst, die eine interne Benutzerin ist.


Authentifizierungsablauf für Services im Zusammenhang mit internen Benutzern
  1. Wenn die BillingApp einen API-Aufruf auslöst, muss sie zuerst ein JWT vom Guidewire Hub anfordern. Die Anforderung des JWT umfasst die Client-ID (0oaqt9pl1vZK1kybt0h7), das Geheimnis (aSecret), die API-Rolle der Anwendung (scp.pc.acme_billingApp), die Ressourcenzugriffsstrategie der Anwendung (pc.service), die Tatsache, dass der Aufruf für einen Benutzer (pc.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.pc.acme_billingapp), die Ressourcenzugriffsstrategie (pc.service), den Wert pc.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 (pc_username) und die Ressourcenzugriffs-ID (aapplegate@acme.com) angibt, an PolicyCenter.
  5. PolicyCenter 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.pc.acme_billingapp) wird der Zugriff auf der Serviceebene mithilfe der API-Rollendatei acme_billingapp.role.yaml definiert.
  6. Als Nächstes bestimmt PolicyCenter den Endpunktzugriff auf der Benutzerebene.
    1. Mit dem Benutzernamen im Benutzerkontext-Header (aapplegate@acme.com) fragt PolicyCenter die Benutzerrollen ab, die dieser Benutzer hat. Eine Rolle wird zurückgegeben: Underwriter.
    2. Ausgehend von der zurückgegebenen Rolle wird die Underwriter.role.yaml-API-Rollendatei verwendet, um den Zugriff auf der Benutzerebene zu definieren.
  7. PolicyCenter 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 (pc.service) wird der Ressourcenzugriff auf der Serviceebene laut Definition in der Datei service access.yaml gewährt. (* PolicyCenter beginnt mit service_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „service“ beginnen.)
  8. PolicyCenter bestimmt die Ressourcenzugriffsstrategie auf der Benutzerebene. Ausgehend vom Wert der Ressourcenzugriffsstrategie im Benutzerkontext-Header (pc_username) wird der Ressourcenzugriff auf Benutzerebene laut Definition in den internal access.yaml-Dateien gestattet. (* PolicyCenter 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. PolicyCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der interne Benutzer: aapplegate@acme.com.
    2. Der Endpunktzugriff ist die Schnittmenge der auf der Serviceebene (acme_billingapp.role.yaml) und auf der Benutzerebene (Underwriter.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 service 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 service 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. PolicyCenter stellt die Antwort auf den ersten Aufruf bereit.

Services mit Benutzerkontext: externe Benutzer

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


Authentifizierungsablauf für Services im Zusammenhang mit externen Benutzern
  1. Wenn die BillingApp einen API-Aufruf auslöst, muss sie zuerst ein JWT vom Guidewire Hub anfordern. Die Anforderung des JWT umfasst die Client-ID (0oaqt9pl1vZK1kybt0h7), das Geheimnis (aSecret), die API-Rolle der Anwendung (scp.pc.acme_billingApp), die Ressourcenzugriffsstrategie der Anwendung (pc.service), die Tatsache, dass der Aufruf für einen Benutzer (pc.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.pc.acme_billingapp), die Ressourcenzugriffsstrategie (pc.service), den Wert pc.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 (pc_accountNumbers) und die Ressourcenzugriffs-ID (464778619) angibt, an PolicyCenter.
  5. PolicyCenter 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.pc.acme_billingapp) wird der Zugriff auf der Serviceebene mithilfe der API-Rollendatei acme_billingapp.role.yaml definiert.
  6. Als Nächstes bestimmt PolicyCenter den Endpunktzugriff auf der Benutzerebene. Ausgehend vom Inhalt des groups-Token-Claims im Benutzerkontext-Header (gwa.prod.pc.Account_Holder) wird der Zugriff auf der Benutzerebene mithilfe der API-Rollendatei Account_Holder.role.yaml definiert.
  7. PolicyCenter 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 (pc.service) gewährt PolicyCenter den Ressourcenzugriff auf der Serviceebene laut Definition in der Datei service access.yaml. (* PolicyCenter beginnt mit service_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „service“ beginnen.)
  8. Als Nächstes bestimmt PolicyCenter die Ressourcenzugriffsstrategie auf der Benutzerebene. Ausgehend vom Wert der Ressourcenzugriffsstrategie im Benutzerkontext-Header (pc_accountNumbers) wird der Ressourcenzugriff auf Benutzerebene laut Definition in den accountNumbers access.yaml-Dateien gewährt. (* PolicyCenter beginnt mit accountNumbers_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „accountNumbers“ beginnen.)
  9. Um zu bestimmen, welcher Proxy-Benutzer der Sitzung zugewiesen werden soll, greift PolicyCenter auf das RestAuthenticationSourceCreator-Plugin zu. Der Benutzerkontext-Header hat eine Ressourcenzugriffsstrategie mit dem Namen pc_accountNumbers festgelegt. Das Plugin gibt somit den Proxy-Benutzer für externe Benutzer zurück: extuser.
  10. PolicyCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der externe Proxy-Benutzer: extuser.
    2. Der Endpunktzugriff ist die Schnittmenge der auf der Serviceebene (acme_billingapp.role.yaml) und auf der Benutzerebene (Account_Holder.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 der Schnittpunkt zwischen den Ressourcen, auf die der Service zugreift (wie in service access.yaml definiert) und den Ressourcen, die dem Benutzer zur Verfügung stehen (wie in der Datei accountNumbers access.yaml mit der Ressourcenzugriffs-ID von 464778619 definiert). In der Basiskonfiguration werden alle Ressourcen durch die Dateien service 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. PolicyCenter stellt die Antwort auf den ersten Aufruf bereit.