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 ClaimCenter, 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.
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, ClaimCenter executes an asymmetric public key lookup. Periodically, ClaimCenter must request the keys used in these lookups from Guidewire Hub.
When you register ClaimCenter with Guidewire Hub, you are given an auth server URI and a tenant ID. For ClaimCenter to be able to request keys from Guidewire Hub, you must add the auth server URI to your ClaimCenter instance.
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.
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.
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.