Functionality of specific resource access strategies

The contactAuthorizationIds resource access strategy

The contactAuthorizationIds resource access strategy is designed to provide access for claimants. This strategy accepts an array of one or more contact authorization IDs. It provides callers with access to resources associated with claims where at least one of the provided contacts has an appropriate business relationship with the resource.

For example, suppose a caller made a request with the following JWT.

"scp": [
  "cc_contactAuthorizationIds",
  "tenant.acme",
  "project.default",
  "planet_class.prod"
],
"groups": [
  "gwa.prod.cc.Claimant"
],
"cc_contactAuthorizationIds": [
  "cm:123890",
  "cm:445566"
]

Based on the cc_contactAuthorizationIds token, the caller would have access to resources where either contact cm:123890 or contact cm:445566 had an appropriate business relationship with the resource. For example, the caller can access any claim where contact cm:123890 or contact cm:445566 is listed on the claim's policy as the insured or a covered party. The caller could also access any exposure on those claims where contact cm:123890 or contact cm:445566 is the exposure's claimant.

Assigning authorization IDs to contacts

The contactAuthorizationIDs resource access strategy requires the following to be true:

Every caller using the strategy is represented in the ClaimCenter database as a ClaimContact who is associated with a Contact with an authorization ID.
The JWT includes that authorization ID.

When determining how to assign authorization IDs, the insurer must consider several use cases. This includes assigning authorization IDs to the following:

Contacts newly created in ClaimCenter
Contacts created in another Guidewire application, such as PolicyCenter
Contacts migrated from another system or previous version of ClaimCenter

For more information on how to assign authorization IDs, see Configuring contact authorization IDs.

Filtered access to third-party data

For some types of callers, some resources contain data that is third-party data from the perspective of the caller. This applies to external users using the contactAuthorizationIds strategy.

For example, suppose Ray Newton is a policyholder who files a claim. The claim involves two damaged vehicles: his own and one owned by a third party named Bo Simpson. Ray Newton can access his own ClaimContact and the information about his vehicle. But, the Bo Simpson ClaimContact and Bo Simpson's vehicle both contain third-party data. They include information such as Bo Simpson's telephone number and the value of Bo Simpson's vehicle. Ray Newton should not have access to this information.

To control access to third-party data, Cloud API uses additional accessible fields filters. These filters are expressions that check the business relationship a caller has with each resource. The filter can limit which fields the caller can view or edit.

For more information on filtered access to third-party data, see Filtered access to third-party data.

The producerCodes resource access strategy

The producerCodes resource access strategy accepts an array of one or more producer codes. It provides callers with access to resources associated with claims where the producer code for the producer of service on the claim's policy is one of the provided producer codes.

For example, suppose a caller made a request with the following JWT.

"scp": [
  "cc_producerCodes",
  "tenant.acme",
  "project.default",
  "planet_class.prod"
],
"groups": [
  "gwa.prod.cc.Producer"
],
"cc_producerCodes": [
  "100-002541",
  "100-002542",
  "100-002543"
]

Based on the cc_producerCodes token, the caller would have access to claims in which the producer code for the producer of service was 100-002541, 100-002542, or 100-002543.

Determining who the producer of service is

Every claim's policy which has a ProducerCodeOfService field. When checking to see if a given producer can access a given claim, Cloud API checks to see if one of the producer codes in the JWT matches the value of the ProducerCodeOfService field.

For producerCode access to work, the claim's ProducerCodeOfService field must be set with a value from the Policy Administration System (PAS) that identifies the producer of service at the time the claim is filed. If your instance of ClaimCenter supports producer access, Guidewire recommends you ensure that the integration point with the PAS includes this value when the policy is copied.

Large numbers of producer codes and the IExpandTokenPlugin plugin

For some insurers, a single producer can have hundreds of producer codes. The entire set of producer codes may be needed to determine which claims a producer can access. But, there can be performance issues if hundreds of producers are included in the SAML response from the IdP, or if hundreds or producers are included in a JWT that Guidewire Hub creates and hands off to ClaimCenter.

To address potential performance issues, Cloud API also supports the IExpandTokenPlugin plugin. This is a plugin that "expands" the information in the JWT with additional information from an external system. The expansion occurs after the JWT has been received from Guidewire Hub but before Cloud API process authorization. Insurers can use this plugin to retrieve additional information relevant to authorization.

Note: Most access information in a JWT can either be included in the SAML response to Guidewire Hub or can be added by the IExpandTokenPlugin plugin. However, if your producer callers require a large number of producer codes, then Guidewire recommends adding the producer codes only through the IExpandTokenPlugin plugin. This helps prevent performance issues that can occur when sending large numbers of values in a SAML response to Guidewire Hub and putting those values in the JWT Guidewire Hub sends to the caller.

Note: Guidewire does not recommend executing calls where the producerCode list has more than 1000 elements. Producer codes are added to the database query's where clause. Database queries begin to degrade when the number of values in the where clause exceeds 1000.

For more information on configuring this plugin, see Configuring the IExpandTokenPlugin plugin.

Filtered access to third-party data

For some types of callers, some resources contain data that is third-party data from the perspective of the caller. This applies to external users using the producerCodes strategy.

For example, suppose Karen Egerston is a producer who is managing a claim for a policyholder named Ray Newton. Ray has filed a claim. The claim involves two damaged vehicles: Ray's vehicle and one owned by a third party named Bo Simpson. Karen Egerston can access the Ray Newton ClaimContact and the information about his vehicle. But, the Bo Simpson ClaimContact and Bo Simpson's vehicle both contain third-party data. They include information such as Bo Simpson's telephone number and the value of Bo Simpson's vehicle. Karen Egerston should not have access to this information.

To control access to third-party data, Cloud API uses additional accessible fields filters. These filters are expressions that check the business relationship a caller has with each resource. The filter can limit which fields the caller can view or edit.

For more information on filtered access to third-party data, see Filtered access to third-party data.

The policyNumbers resource access strategy

Note: Guidewire recommends insurers use the cc_contactAuthoriationIds strategy instead of the cc_policyNumbers strategy. The cc_contactAuthoriationIds strategy is more robust, as it provides additional configuration options and is appropriate for both insureds and third-party claimants. The information in the following section is intended for insurers who adopted the cc_policyNumbers strategy prior to the availability of the cc_contactAuthoriationIds strategy.

The policyNumbers resource access strategy requires an array of one or more policy numbers. It provides callers with access to resources associated with claims whose policy number is one of the provided policy numbers. This strategy is not appropriate for third-party claimants, as it assumes the caller is the policyholder of the policies listed in the JWT.

Restricted access to ClaimContacts, incidents, and exposures

This resource access strategy is intended to provide insureds with access to their claims. However, claims often contain information about third parties, such as third-party ClaimContacts, third party vehicles, and third-party exposures. Typically, insureds should not have access to third-party information.

Therefore, the policyNumbers resource access strategy enforces a special behavior around access to ClaimContacts, incidents, and exposures. Callers can view and edit only the ClaimContacts that are related to the policy with the role of Insured. They can view and edit only the incidents that are related to a ClaimContact that is related to the policy with the role of Insured. And, they can view only the exposures where the claimant is a ClaimContact with the role of Insured. They cannot view any of the following:

Information about ClaimContacts that are not related to the policy (such as a third-party ClaimContact or a vendor).
Information about ClaimContacts that are related to the policy but without this role of Insured (such as an agent).
Information about any incident that is not related to an Insured ClaimContact (such as a third-party incident).
Information about any exposure where the claimant is not a ClaimContact with the role of Insured (such as an exposure for a third-party incident).

For example, suppose Ray Newton files a claim for an accident involving himself and another driver, David Preston. Ray's vehicle is repaired by Sam's Towing and Auto Service. The claim has two vehicle incidents: one for Ray Newton's vehicle and one for David Preston's vehicle. Each incident has an exposure.

Ray Newton can do the following:
- View information about himself, as this ClaimContact is related to the policy with the role of Insured.
- View information about his vehicle incident, as this incident is related to himself, and he is related to the policy with the role of Insured.
- View information about the exposure, as he is listed as the claimant for the exposure, and he has the role of insured.
- Create new ClaimContacts and new incidents.
Ray Newton cannot do the following:
- View or edit information about David Preston
- View or edit information about Sam's Towing
- View or edit information about David Preston's vehicle incident
- View or edit information about any ClaimContacts he created that are not related to the policy with the role of Insured.
- View or edit information about any incidents he created that are not related to a ClaimContact that is an Insured on the policy.
- View information about any exposures where the claimant does not have the role of insured.

The service resource access strategy

Most of the resource access strategies specify restrictions, which limit the resource and fields that a caller can view.

However, the cc.service resource access strategy specifies almost no restrictions. This is because this resource access strategy is designed to be used by services. Services are expected to be configured such that they access only the resources appropriate for the circumstance. Consequently, JWTs for API calls from services do not typically include resource access IDs.

Note that resource access for the different service-related auth flows behave as described here:

For standalone services, calls use the cc.service resource access strategy. Therefore, they have unrestricted resource access.
For services with user context, each call's resource access is the intersection of the service-level resource access and the user-level resource access. The service-level resource access is the cc.service resource access strategy, which has no restrictions. Therefore, logically speaking, a service-with-user-context call has resource access equivalent to the user-level resource access.
For services with service account mapping, the service is mapped to an internal service account. The cc.service resource access strategy is not used. Rather, the call uses the cc_username resource access strategy.