ContactManager-Authentifizierung

Die Authentifizierung für Cloud-API für ContactManager ist nahezu identisch mit der Authentifizierung für Cloud-API für ClaimCenter. In diesem Abschnitt werden die Unterschiede zwischen den beiden beschrieben. Wenn ein Thema hier nicht ausdrücklich behandelt wird, können Sie davon ausgehen, dass es sich für die beiden Anwendungen gleich verhält.

Unterstützte Aufrufertypen

Die Cloud-API für ContactManager unterstützt die folgenden Aufrufertypen:

  • Basisauthentifizierung
  • Interne Benutzer (mit Bearer-Token-Authentifizierung)
  • Eigenständige Services
  • Services mit Benutzerkontext (wobei der Benutzerkontext auf einen internen Benutzer verweist)
  • Services mit Servicekontozuordnung
  • Nicht authentifizierte Aufrufer

Die Cloud-API für ContactManager verfügt über keine Ressourcenzugriffsdateien. Cloud-API für ContactManager unterstützt daher nicht:

  • Externe Benutzer
  • Services mit Benutzerkontext, bei denen der im Kontext benannte Benutzer ein externer Benutzer ist

In PolicyCenter besteht eine Geschäftsanforderung, dass ein Benutzer in der Lage sein muss, ein Konto zu erstellen und ein Angebot für eine Police zu erstellen, ohne dem Versicherer bekannt zu sein. Daher unterstützt die Cloud-API für PolicyCenter anonyme Benutzer. Für ContactManager besteht keine analoge Geschäftsanforderung. Daher unterstützt die Cloud-API für ContactManager keine anonymen Benutzer.

Ressourcenzugriff für ContactManager

Die Basiskonfiguration der Cloud-API für ContactManager enthält keine Ressourcenzugriffsdateien. Daher sind Aufrufer nicht durch Ressourcenzugriff eingeschränkt.

Tag-basierter Zugriff auf Kontakte

Kontakte in ContactManager verfügen über Kontakt-Tags. Ein Kontakt-Tag ist ein Tag, das eine oder mehrere umfassende Beziehungen identifiziert, die ein Kontakt mit dem Versicherer hat

In der Basisanwendung sind drei Tags verfügbar:

  • Kunde (ein Versicherungsnehmer)
  • Schadensfallpartei (ein an einem Schadensfall beteiligter Kontakt)
  • Anbieter (ein Kontakt, der Dienstleistungen für einen Schadensfall bereitstellt)

Um einen Kontakt mit einem bestimmten Tag-Typ anzuzeigen oder zu bearbeiten, muss ein Benutzer über Berechtigungen für diese Aktion und für dieses Tag verfügen. Zum Beispiel:

  • Um Kontakte mit dem Kunde-Tag anzuzeigen, muss ein Benutzer über die Berechtigung „view client“ verfügen.
  • Um Kontakte mit dem Anbieter-Tag bearbeiten zu können, muss ein Benutzer über die Berechtigung „edit vendor“ verfügen.

Es gibt auch zwei Systemberechtigungen, viewanytag und editanytag, mit denen die zugehörigen Benutzer Kontakte unabhängig von den Tags des Kontakts anzeigen oder bearbeiten können.

Verhalten der Tag-basierten Berechtigungen in der Basiskonfiguration

In der ContactManager-Basiskonfiguration verfügen alle Benutzer entweder über das viewanytag, das editanytag oder über beide. Das bedeutet, dass alle Benutzer der Basiskonfiguration Tag-basierte Berechtigungen umgehen.

Cloud-API-Zugriff und Tag-basierte Berechtigungen

Tag-basierte Berechtigungen gelten für Aufrufer, die über die Cloud-API auf Kontakte zugreifen. Um Kontakte mit einem bestimmten Tag-Typ anzuzeigen oder zu bearbeiten, muss Folgendes zutreffen:

  • Für interne Benutzer und Services mit Servicekontozuordnung:
    • Entweder verfügt der Aufrufer über die entsprechende Berechtigung „view <tag>“ und/oder „edit <tag>“, ODER
    • Der Aufrufer verfügt über die viewanytag-Berechtigung und/oder die editanytag-Berechtigung
  • Für eigenständige Services und Services mit Benutzerkontext:
    • Der Proxy-Benutzer verfügt entweder über die entsprechende Berechtigung „view <tag>“ und/oder „edit <tag>“, ODER
    • Der Proxy-Benutzer verfügt über die viewanytag-Berechtigung und/oder die editanytag-Berechtigung

Beachten Sie, dass bei internen Benutzern und Services mit Servicekontozuordnung die Berechtigungsprüfung für jeden Aufrufer einzeln erfolgt. Das bedeutet, dass bei einem bestimmten „view <tag>“- oder „edit <tag>“-Szenario einige Aufrufer Zugriff auf den Kontakt erhalten, andere nicht.

Bei eigenständigen Services und Services mit Benutzerkontext erfolgt die Berechtigungsprüfung jedoch für den einen Benutzer, der als Proxy-Servicebenutzer festgelegt ist. Das bedeutet, dass für ein bestimmtes „view <tag>“- oder „edit <tag>“-Szenario entweder alle Aufrufer dieses Aufrufertyps oder keiner von ihnen Zugriff auf den Kontakt haben.