ContactManager authentication

Authentication for Cloud API for ContactManager is nearly identical to authentication for Cloud API for PolicyCenter. This topic identifies the differences between the two. If a topic is not explicitly discussed here, you can assume that it behaves in the same way for the two applications.

Supported caller types

Cloud API for ContactManager supports the following caller types:

  • Basic auth
  • Internal users (using bearer token auth)
  • Standalone services
  • Services with user context (where the user context references an internal user)
  • Services with service account mapping
  • Unauthenticated callers

Cloud API for ContactManager does not have any resource access files. Therefore, Cloud API for ContactManager does not support:

  • External users
  • Services with user context where the user named in the context is an external user

In PolicyCenter, there is a business need for a user to be able to create an account and quote a policy without being known to the insurer. Therefore, Cloud API for PolicyCenter supports anonymous users. The is no analogous business need for ContactManager. Therefore, Cloud API for ContactManager does not support anonymous users.

Resource access for ContactManager

The base configuration of Cloud API for ContactManager does not come with any resource access files. As a result, callers are not restricted by resource access.

Tag-based access to contacts

Contacts in ContactManager have contact tags. A contact tag is a tag that identifies one or more broad relationships that the contact has with the insurer.

The base application includes three tags:

  • Client (a policy holder)
  • Claim party (a contact involved in a claim)
  • Vendor (a contact that provides service for a claim)

In order to view or edit a contact with a given type of tag, a user must have permissions for that action and for that tag. For example:

  • In order to view contacts with the client tag, a user must have a "view client" permission.
  • In order to edit contacts with the vendor tag, a user must have a "edit vendor" permission.

There are also two system permissions, viewanytag and editanytag, that let the associated users view or edit any contact, regardless of the contact's tags.

Base configuration behavior of tag-based permissions

In the ContactManager base configuration, all users have either the viewanytag, the editanytag, or both. This means that all base configuration user bypass tag-based permissions.

Cloud API access and tag-based permissions

Tag-based permissions apply to callers accessing contacts through Cloud API. In order to view or edit contacts with a given type of tag, the following must be true:

  • For internal users and services with service account mapping:
    • Either the caller has an appropriate "view <tag>" permission and/or an appropriate "edit <tag>" permission, OR
    • The caller has the viewanytag permission and/or the editanytag permission
  • For standalone services and services with user context:
    • Either the proxy user has an appropriate "view <tag>" permission and/or an appropriate "edit <tag>" permission, OR
    • The proxy user has the viewanytag permission and/or the editanytag permission

Note that for internal users and services with service account mapping, the permission check occurs against each caller individually. This means that, for a given "view <tag>" or "edit <tag>" scenario, some callers will be given access to the contact while others will not.

However, for standalone service, and services with user context, the permission check occurs against the one user designated as the proxy service user. This means that, for a given "view <tag>" or "edit <tag>" scenario, either all callers of that caller type will have access to the contact, or none of them will.