Configuring contact authorization IDs

Automatic assignment on creation

In every Guidewire InsuranceSuite application, a contact is automatically assigned a contact authorization ID when the contact is created. This value is generated using the same algorithm as the one that generates public IDs. This value is ultimately copied to ContactManager and then shared with all copies of the contact in every InsuranceSuite application.

Prior to Innsbruck, Guidewire InsuranceSuite applications did not generate or store contact authorization IDs. Therefore, any contact created on a release prior to the Innsbruck release will not have a contact authorization ID assigned to them. During the upgrade to Innsbruck, contact authorization IDs are set to null.

If you plan to use a resource access strategy that requires contact authorization IDs, you must assign IDs to these contacts explicitly. You can do so using the auth ID assignment endpoints.

Manual assignment through endpoints

Cloud API includes the following endpoints in the following APIs:

• The ContactManager Contact API
  • POST /contact/v1/contacts/{contactId}/initialize-authorization-id
• The ClaimCenter Claim API
  • POST /claim/v1/claims/{claimId}/contacts/{contactId}/initialize-authorization-id
• The PolicyCenter Account API
  • POST /account/v1//accounts/{accountId}/contacts/{contactId}/initialize-authorization-id
• The BillingCenter Billing API
  • POST /billing/v1/accounts/{accountId}/contacts/{contactId}/initialize-authorization-id
  • POST /billing/v1/accounts/{accountId}/policies/{policyId}/policy-periods/{policyPeriodId}/contacts/{contactId}/initialize-authorization-id

Each of these endpoints assigns a contact authorization ID to the given contact. The request does not require a body.

For example, the following ClaimCenter request assigns a contact authorization ID to contact cc:1145.

POST /claim/v1/claims/{claimId}/contacts/cc:1145/initialize-authorization-id

{
  "data": {
    "attributes": {
      "authorizationID": "So79DQyxjzrQbTN82mlcJ",
      "companyName": "Mike's Auto detailing shop",
      "contactSubtype": "AutoRepairShop",
      "displayName": "Mike's Auto detailing shop",
      "emailAddress1": "0000@guidewire.com",
      "emailAddress2": "0000@email.com",
      "id": "cc:1145",
      ...
    }
...

In the base configuration, there are no user roles with access to this endpoint.

{
  "status": 400,
  "errorCode": "gw.api.modules.rest.framework.v1.exceptions.OperationNotCurrentlyAllowedException",
  "userMessage": "The operation is not currently allowed for this resource"
}

Contacts with no authorization IDs

A contact is not required to have a contact authorization ID. If a contact does not have a contact authorization ID, the only limitation is that a caller who is that contact (or who represents that contact, such as the parent of a minor) cannot access their information using the contactAuthorizationIds resource access strategy.

New user is created by the user themselves through a portal

Suppose the insurer provides a portal where insureds can access information about their policies and claims. Also, suppose there is a person named Donna Howard. She has never purchased a policy from the insurer. She logs on to the insurer's portal and creates a portal account for herself. This adds her username and password to the IdP. During that session, she creates a submission. This involves adding information to the submission that triggers the creation of a Contact in PolicyCenter. The Contact is automatically assigned a contact authorization ID. The insurer maps this ID to her user in the IdP. (If this did not occur, then in any subsequent session, her JWT would not have her authorization ID, and Donna Howard would not be able to access her information using the contactAuthorizationIds strategy.)

Existing insured uses a portal for the first time

Suppose the insurer provides a portal where insureds can access information about their policies and claims. Also, suppose there is a person named Ray Newton. He bought his policy from the insured before this portal existed. He is now using the portal for the first time. He logs on to the insurer's portal and creates a portal account. While doing this, he provides some kind of Knowledge Based Authentication to prove that he is the existing Ray Newton insured. When the portal creates the account, it also makes a call to Cloud API to assign an authorization ID to the Ray Newton contact. The ID is returned in the POST response. The portal stores this in the Ray Newton portal account.

Third-party claimant

Suppose the insurer provides a portal where third-party claimants can access information about their claims, even though they are not insured by the insurer. Also, suppose there is a person named Janet Hendrickson. She does not have a policy with the insurer. She is a third-party claimant who uses the insurer's portal to access information about the claim. She access the portal through some sort of secure link and provides some kind of Knowledge Based Authentication to prove that she is the existing Janet Hendrickson claimant. At this time, the portal checks to see if she already has a contact authorization ID. If she does not, the portal makes a call to Cloud API to assign an authorization ID to the Janet Hendrickson contact. This authorization ID is then including in the JWT used to retrieve her information.

Customer service representative is acting on behalf of an insured

Suppose the insurer provides a Customer Service Representative (CSR) portal used by CSRs to help them access claim information without needing to log on to ClaimCenter. Then, suppose there is a person named Robert Astin. He calls the insurer and speaks with a Customer Service Representative (CSR). Robert provides some kind of Knowledge Based Authentication to prove that he is the existing Robert Astin insured. The CSR enters this information into the CSR portal to query for information about Robert's claim. At this time, the portal checks to see if he already has a contact authorization ID. If he does not, the portal makes a call to Cloud API to assign an authorization ID to the Robert Astin contact. This authorization ID is then including in the JWT used to retrieve her information.