Beispielablauf für anonyme Benutzer

Das folgende Diagramm stellt den Austausch von Authentifizierungs- und Autorisierungsinformationen bei nicht authentifizierten Aufrufern dar. 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).

Der anonyme Benutzerablauf umfasst immer mindestens zwei Aufrufe. Beim ersten Aufruf ist der Benutzer nicht authentifiziert. Beim zweiten ist der Benutzer anonym.

Der ursprüngliche Aufruf als nicht authentifizierter Benutzer

Im folgenden Beispiel wird ein API-Aufruf von einem nicht authentifizierten Aufrufer ausgelöst, der ein Konto erstellt und später plant, einen Policenantrag verbindlich zu machen.


Erster Authentifizierungsablauf für nicht authentifizierte Aufrufer
  1. Der Benutzer löst einen API-Aufruf durch das Erstellen eines neuen Kontos aus. Die aufrufende Anwendung sendet die API-Anforderung an PolicyCenter. Der Aufruf enthält kein JWT und keine Authentifizierungsinformationen im Header.
  2. Da der Aufruf keinen Authentifizierungsheader hat, gewährt PolicyCenter den Endpunktzugriff gemäß der Definition in der API-Rollendatei Unauthenticated.role.yaml. (Dies ermöglicht nur den Zugriff auf Metadatenendpunkte.)
  3. Da der Aufruf keinen Authentifizierungsheader hat, gewährt PolicyCenter den Ressourcenzugriff gemäß der Definition in der API-Rollendatei unauthenticatedUser.role.yaml. (Dies ermöglicht keinen Zugriff auf Geschäftsressourcen.)
  4. Um zu bestimmen, welcher Proxy-Benutzer der Sitzung zugewiesen werden soll, greift PolicyCenter auf das RestAuthenticationSourceCreator-Plugin zu. Der Aufruf hat keinen Authentifizierungsheader. Das Plugin gibt somit den Proxy-Benutzer für nicht authentifizierte Benutzer zurück: uauser.
  5. PolicyCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der nicht authentifizierte Proxy-Benutzer: uauser.
    2. Der Endpunktzugriff wird durch die Datei Unauthenticated.role.yaml definiert. (Diese API-Rolle bietet einen ausreichenden Endpunktzugriff, um ein neues Konto und die erforderlichen untergeordneten Objekte wie Kontakte und Orte zu erstellen.)
    3. Der Endpunktzugriff wird durch die Datei unauthenticatedUser access.yaml definiert.
  6. PolicyCenter stellt die Antwort auf den ersten Aufruf bereit. Die Antwort enthält die Kontonummer für das neu erstellte Konto (464778619) und ein selbstsigniertes JWT, die von PolicyCenter generiert wird. Das JWT enthält die Client-ID (cid), einen scp-Token Claim, der die Ressourcenzugriffsstrategie (pc_accountNumbers) und zusätzliche Bereitstellungsinformationen festlegt, einen groups-Token, der die Gruppen des Benutzers festlegt (gwa.prod.pc.anonymous), und einen pc_accountNumbers-Token, der die Ressourcenzugriffs-IDs des Benutzers festlegt (464778619).

Der zweite Aufruf als anonymer Benutzer

In der Fortsetzung des Beispiels wird ein zweiter API-Aufruf von einem zuvor nicht authentifizierten Aufrufer ausgelöst, der jetzt anonym ist. Dieser Aufruf erstellt einen Policenantrag und macht ihn verbindlich.


Zweiter Authentifizierungsablauf für nicht authentifizierte Aufrufer
  1. Der Benutzer löst einen API-Aufruf aus, indem er versucht, eine Police zu erstellen und verbindlich zu machen. Die aufrufende Anwendung sendet die API-Anforderung an PolicyCenter. Der Aufruf enthält das selbstsignierte JWT.
  2. PolicyCenter bestimmt den Endpunktzugriff. Ausgehend von den im JWT enthaltenen Gruppen (gwa.prod.pc.anonymous) wird der Endpunktzugriff mithilfe der API-Rollendateianonymous.role.yaml definiert.
  3. Als Nächstes bestimmt PolicyCenter die Ressourcenzugriffsstrategie. Ausgehend von dem im JWT enthaltenen Wert der Ressourcenzugriffsstrategie (pc_accountNumbers) wird der Ressourcenzugriff laut Definition in der Datei accountholder access.yaml gewährt. (* PolicyCenter beginnt mit accountholder_ext-1.0.access.yaml, aber diese Datei verweist auf zusätzliche access.yaml-Dateien, deren Namen mit „accountholder“ beginnen.)
  4. Um zu bestimmen, welcher Proxy-Benutzer der Sitzung zugewiesen werden soll, greift PolicyCenter auf das RestAuthenticationSourceCreator-Plugin zu. Das JWT hat eine Ressourcenzugriffsstrategie für pc_accountNumbers festgelegt. Das Plugin gibt somit den Proxy-Benutzer für externe Benutzer zurück: extuser.
  5. PolicyCenter verarbeitet die Anforderung.
    1. Der Sitzungsbenutzer ist der externe Proxy-Benutzer: extuser.
    2. Der Endpunktzugriff wird durch die Datei anonymous.role.yaml definiert. (Diese API-Rolle ermöglicht den Zugriff auf für anonyme Benutzer geeignete Aktionen, z. B. Angebotserstellung und Verbindlichmachung von Anträgen.)
    3. Der Ressourcenzugriff wird durch die Datei accountholder access.yaml definiert.
  6. PolicyCenter stellt die Antwort auf den ersten Aufruf bereit.

Wenn die Police des anonymen Benutzers verbindlich gemacht wird, wird der Benutzer dem Versicherer „bekannt“. Zu einem späteren Zeitpunkt werden die Angaben zu dem Benutzer an den IdP gesendet. Sobald dies geschehen ist, wird der Benutzer als externer Benutzer behandelt.