Troubleshooting auth issues

When you encounter an auth issue, the single most effective action you can take to troubleshoot the issue is to set the REST.Config and REST.Request loggers to DEBUG, reproduce the error, and then check the application log for the resulting error messages. Most auth issues trigger log messages that identify the source of the problem.

Be aware of the following:

  • In a standalone instance of PolicyCenter, there is only one log. By default, it is located in /tmp/gwlogs/GenericCenter/logs. In a Cloud or multiclustered instance, there may be multiple logs.

  • Some messages are written to the log only when the REST.Config and REST.Request loggers are set to DEBUG. When troubleshooting auth issues, Guidewire recommends setting these loggers to DEBUG.

For more information on how to configure general PolicyCenter logging, refer to the Server Tools section of the Administration Guide.

Examples of auth errors in the log

The following section lists auth problems that developers have encountered in the past and the way these errors were reflected in the logs. This is not a comprehensive list of all of the errors that you could encounter. It is provided solely to illustrate some of the ways in which log messages can help identify auth problems.

Failing to list your URL as an allowed issuer when enabling asymmetric encryption

Bearer token authentication for Cloud API uses asymmetric encryption. To verify a given JWT, PolicyCenter executes an asymmetric public key lookup. Periodically, PolicyCenter must request the keys used in these lookups from Guidewire Hub.

When you register PolicyCenter with Guidewire Hub, you are given an auth server URI and a tenant ID. For PolicyCenter to be able to request keys from Guidewire Hub, you must add the auth server URI to your PolicyCenter instance.

If you do not enable asymmetric encryption, then Cloud API rejects calls that attempt to use bearer token. A message similar to the following is listed in the logs. (For readability, some hard returns have been added to the text below.)
error","eventType":"STATUS","eventMessage":"Operation status","contextMap":{"path":"/claim/v1/
claims/demo_sample:1/","query":"","method":"GET","from":"[0:0:0:0:0:0:0:1]","async":false,
"pathTemplate":"/claim/v1/claims/{claimId}","apiFqn":"ext.claim.v1.claim_combined_ext-1.0",
"user":"","sub":"","clientId":"","status":401,"error":"gw.api.modules.rest.framework.v1.plugin
.security.InvalidAuthenticationTokenException","userMessage":"Authorization failed","devMessage":
 "JWT verification failed: Encountered JWT issuer 'http://localhost:8080/cc/rest' that has not 
been configured in 'allowedIssuers' by the SignatureKeyProviderPlugin. Allowed issuers are []",
 "auth":"bearer","tokenType":"unrecognized","userContextType":"none","origin":"","userAgent":
"PostmanRuntime/7.26.8","async.1":false,"jutroSdkVersion":""},"elapsedTimeMs":20,"serverId":
"localinstance2us","timestamp":"20230712T144133.394-0700"}

For more information on enabling asymmetric encryption, see Enabling asymmetric encryption.

Failing to allowlist an endpoint in an API role file

By default, callers do not have access to any endpoints. In order to use endpoints, a caller must be associated with an API role, and the API role must explicitly list the endpoints that can be used by callers with that role.

If a caller attempts to call an endpoint that is not explicitly listed in their API roles, then Cloud API rejects the call. A message similar to the following is listed in the logs. (For readability, some hard returns have been added to the text below.)
localinstance2us aapplegate 60bd8cfe-ee14-4580-99f4-670d1f4d4744 2023-07-17 16:20:50,125 INFO 
<RestRequest[ GW.PL ]> {"message":"Client error","eventType":"STATUS","eventMessage":"Operation 
status","contextMap":{"path":"/claim/v1/claims/demo_sample:1/exposures","query":"","method":
"GET","from":"[0:0:0:0:0:0:0:1]","async":false,"pathTemplate":"/claim/v1/claims/{claimId}/
exposures","apiFqn":"ext.claim.v1.claim_combined_ext-1.0","user":"aapplegate","sub":"",
"clientId":"","status":404,"error":"gw.api.rest.exceptions.NotFoundException","userMessage":
"No view permission for the requested resource","devMessage":"","auth":"basic","tokenType":
"none","userContextType":"none","origin":"","userAgent":"PostmanRuntime/7.26.8","async.1":
false,"jutroSdkVersion":""},"elapsedTimeMs":5,"serverId":"localinstance2us","timestamp":
"20230717T162050.124-0700"}

Cloud API writes a log message for each check it performs to see if paths and operations are accessible. The log message lists the roles that have been checked and whether the roles grant access. For example, suppose a caller attempts to access GET /claims/{claimId}/exposures. Also, suppose the caller has two roles, "Adjuster" and "Trusted for Sensitive Claims", but neither role grants access to this endpoint. When the call fails, Cloud API writes the following to the log.

pniemeyer2us aapplegate 2b79fe61-75af-4d77-aedb-838864882163 2023-07-17 16:20:44,274 DEBUG 
    Checking access to path and operation based off roles.
	Path: '/claim/v1/claims/demo_sample:1/exposures'
	httpMethod: 'GET'
	Roles: {Trusted for Sensitive Claims, Adjuster}
	Roles acquired from: token
	Roles grant access: false

When trying to track down "no <action> permission" errors, it may be helpful to search for the error messages containing the string Roles grant access: false.

Note that the error message says Roles acquired from: token. This means that the roles were retrieved using information from the JWT, but the roles may not have been explicitly listed on the JWT. For internal users, roles come from a database query to the cc_user, pc_user, or bc_user table using information in the JWT. For external users, roles could come from the JWT or from information retrieved by the IExpandTokenPlugin.

For more information on endpoint access, see Endpoint access.

Failing to provide a service role scope in a JWT for a service call

When a call is made by a service, the JWT must contain a scp claim with one of the following values:

  • cc.service (for calls to Cloud API for ClaimCenter)
  • pc.service (for calls to Cloud API for PolicyCenter)
  • bc.service (for calls to Cloud API for BillingCenter)

If a service sends a call, but the correct scope is not included in the JWT, then Cloud API rejects the call.

For more information on registering scopes, see Registering the caller application with Guidewire Hub.