How the contactAuthorizationIds strategy manages access

The contactAuthorizationIds strategy is one of the access strategies that manages access to third-party data. The following topic describes the third-party data access behaviors of this strategy in the base configuration.

The contactAuthorizationIds strategy determines who the user is by looking for a cc_contactAuthorizationIds claim in the JWT. This claim contains a list of contact authorization IDs that correspond to the user and any other person the user can represent (such as a parent creating a claim for a minor listed on their policy).

Resources

This strategy controls access to third-party data for the following resource types:

Claim
Policy
ClaimContact
Incident
AssessmentContentItem
Exposure

Internal "hasAccessOn<Resource>" methods

This strategy uses the following internal methods:


Method	Returns true if...
`user.hasPrivilegedRoleOnClaim`	The user's JWT has a contact authorization ID that maps to a contact that has a role on the policy that is listed in `ClaimPriviledgedRoles.yaml`
`user.hasExternalUserPrivilegedAccessOnClaimContact`	The user's JWT has a contact authorization ID that maps to a contact that is associated with the ClaimContact.
`user.hasExternalUserPrivilegedAccessOnIncident`	The user's JWT has a contact authorization ID that maps to a contact that has a role on the incident.
`user.hasExternalUserPrivilegedAccessOnExposure`	The user's JWT has a contact authorization ID that maps to a contact that is the claimant on the exposure.

ClaimContact role yaml files

This strategy uses the following files:

ClaimPrivilegedRoles.yaml
- In the base configuration, this lists: coveredparty, insured
- This is used by the "hasAccessOn<Resource>" methods that check for access to the claim itself.

You can modify the contents of the ClaimPrivilegedRoles.yaml file. Technically, you can list any type of role in this file. But any string that is not a policy role is ignored.

Warning: Do not delete or rename the ClaimPrivilegedRoles.yaml file itself. Doing so will cause the contactAuthorizationIds resource access strategy to not behave as expected.

accessiblefields.yaml files

This strategy uses the following files:

restricted.accessiblefields.yaml
thirdpartyprivileged.accessiblefields.yaml

Behaviors for each resource type

For every resource and action, there are different behaviors for users who are claim-privileged and users who are not. Broadly speaking, a claim-privileged user is a user who is listed on the policy. A user who is not claim-privileged is a third-party claimant. (More technically speaking, a claim-privileged user is a user who is also a ClaimContact with a given role on the policy. In the base configuration, the given roles are coveredparty and insured. A non-claim-privileged user is any user who is not a coveredparty and insured on the policy.)

To simplify the table as much as possible, the table makes use of the following terms:

JWT contact - Any contact whose contact authorization ID is listed in the JWT
- A user can have a JWT that lists multiple contacts. For example, if Ray Newton is a policyholder and the policy covers his son, Stan Newton, then Ray Newton's JWT may list both his contact ID and his son's contact ID.
Restricted access - Access that is filtered according to the restricted.accessiblefields.yaml file.
Third-party privileged access - Access that is filtered according to the thirdpartyprivileged.accessiblefields.yaml file


Behavior	Claim-privileged	Not claim-privileged
Claim
Create claim	See Creating claims as an external user.	See Creating claims as an external user.
View claim	If at least one of the JWT contacts is claim privileged, the user has privileged view access to the claim.	If at least one of the JWT contacts is listed on the claim, but none of the JWT contacts are claim privileged, the user has restricted view access to the claim.
Edit claim	If at least one of the JWT contacts is claim privileged, the user has privileged edit access to the claim.	If none of the JWT contacts are claim privileged, the user cannot edit the claim.
Policy
Create policy	Not applicable (Policies are created only by integration code with the PAS.)	Not applicable (Policies are created only by integration code with the PAS.)
View policy	If at least one of the JWT contacts is claim privileged, the user has privileged view access to the policy.	If none of the JWT contacts are claim privileged, the user cannot view the policy.
Edit policy	The policy cannot be edited through Cloud API.	The policy cannot be edited through Cloud API.
ClaimContact
Create ClaimContact	If at least one of the JWT contacts is claim privileged, the user may create ClaimContacts. They have privileged access to the fields they can set. The response has a restricted view of the ClaimContact. This is because the ClaimContact has just been created and therefore is not included in the user's JWT.	If none of the JWT contacts are claim privileged, the user cannot create ClaimContacts.
View ClaimContact	If at least one of the JWT contacts is claim privileged, the user has: Privileged view access to ClaimContacts listed in the JWT Restricted view access to all other ClaimContacts on the claim	If none of the JWT contacts are claim privileged, the user has: Privileged view access to ClaimContacts listed in the JWT No access to any other ClaimContact on the claim
Edit ClaimContact	The user has: Privileged edit access to ClaimContacts listed in the JWT (and a privileged view of the response) No edit access to any other ClaimContacts on the claim	The user has: Privileged edit access to ClaimContacts listed in the JWT (and a privileged view of the response) No edit access to any other ClaimContacts on the claim
Incidents
Create incident	If at least one of the JWT contacts is claim privileged, the user may create incidents. They have privileged access to the fields they can set. If the incident is associated with one of the JWT contacts, the response has a privileged view of the incident. Otherwise, it has a restricted view.	If none of the JWT contacts are claim privileged, the user cannot create incidents.
View incident	If at least one of the JWT contacts is claim privileged, the user has: Privileged view access to incidents where one of the JWT contacts has a role on the incident. Restricted view access to all other incidents on the claim	If none of the JWT contacts is claim privileged, the user has: Third-party privileged view access to incidents where one of the JWT contacts has a role on the incident. No access to other incidents on the claim
Edit incident	A user has privileged edit access to incidents where one of the JWT contacts has a role on the incident. (Users cannot edit incidents where none of the JWT contacts have a role on the incident.)	A user has third party privileged edit access to incidents where one of the JWT contacts has a role on the incident. (Users cannot edit incidents where none of the JWT contacts have a role on the incident.)
Create child of incident (such as assessment items)	If at least one of the JWT contacts has a role on the incident, the user may view all child objects of the incident. They have privileged access to the fields they can set. They see a privileged view of the incident in the response.	If at least one of the JWT contacts has a role on the incident, the user may create child objects of the incident. They have privileged access to the fields they can set. They have a third party privileged view of the incident in the response.
View child of incident	If at least one of the JWT contacts is claim privileged, the user can view all children of all incidents. The user has: Privileged view access to child objects on all incidents Restricted view access to all other ClaimContacts on the claim	If none of the JWT contacts is claim privileged, the user can view only the incidents where at least one of the JWT contacts has a role on the incident. The user has: Third party privileged view access to those children.
Edit child of incident	If at least one of the JWT contacts has a role on the incident, the user may edit all child objects of the incident. They have privileged access to the fields they can edit. They see a privileged view of the child in the response.	If at least one of the JWT contacts has a role on the incident, the user may edit all child objects of the incident. They have third party privileged access to the fields they can edit. They see a third party privileged view of the incident in the response.
Exposures
Create exposure	The user cannot create exposures.	The user cannot create exposures.
View exposure	The user may view exposures. The user has an unfiltered view of exposures where the claimant is a JWT contact. The user has a filtered view of exposures where the claimant is not a JWT contact.	The user may view exposures. The user has a third-party privileged filtered view to exposures where the claimant is a JWT contact. The user cannot view exposures where the claimant is not a JWT contact.
Edit exposure	The user cannot edit exposures.	The user cannot edit exposures.
Service requests
Create service request	The user cannot create service requests.	The user cannot create service requests.
View service request	The user may view service requests. The user has an unfiltered view of service requests where the service request's customer is a JWT contact. The user has a filtered view of service requests where the service request's customer is not a JWT contact. Service request access can also be limited by the types of services in the request. For more information, see Restricting access to service requests based on its services.	The user may view exposures. The user has a third-party privileged filtered view to service requests where the service request's customer is a JWT contact. The user cannot view exposures where the service request's customer is not a JWT contact. Service request access can also be limited by the types of services in the request. For more information, see Restricting access to service requests based on its services.
Edit service request	The user cannot edit service requests.	The user cannot edit service requests.

Creating claims as an external user

An insured can create a new claim. However, Cloud API permits this only for policies that are associated with the insured. Prior to the creation of a claim, there may be no information in ClaimCenter about which policies an insured is associated with. Therefore, Cloud API expects this information to be included in the JWT.

When an insured makes a request to create a claim, the JWT must include a cc_policyNumbers claim with the appropriate policy number. This is in addition to the cc_contactAuthorizationIds claim that lists the external user themselves.

For example, suppose the following JWT is submitted by Ray Newton, an insured who is contact cm:012879. This would allow Ray Newton to create a claim for policy PA-123456.

[
  "groups": [
    "gwa.prod.cc.Claimant"
  ],
  "cc_contactAuthorizationIds": [
    "cm:012879"
  ],
  "cc_policyNumbers": [
    "PA-123456"
  ],
 ...
]

When Cloud API receives a JWT with both a cc_contactAuhorizationIds claim and a cc_policyNumbers claim, Cloud API uses the contactAuthorizationIds resource access strategy.

If the call is POSTing a claim, Cloud API verifies that:

The policy named in the request body matches the policy named in the JWT.
One of the contacts listed in the JWT has one or the appropriate roles on the policy (such as insured or coveredparty).

If both of these conditions are true, the user has unfiltered permission to write fields on the claim, and the user will have an unfiltered view of the claim in the response.

For insureds, the cc_policyNumbers claim is needed only for requests using POST /claim/v1/claims. It is not needed for any other endpoint used by insureds, but there is no harm in including it.

Guidewire recommends against putting the cc_policyNumbers claim on JWTs for third-party claimants. By definition, a third-party claimant does not have an appropriate role on the policy. This limits them to having filtered access to the claim, and filtered access for claims does not contain any writeable fields.