Example flow for standalone services

The following diagram identifies the flow of authentication and authorization information for standalone services. Colors are used in the following ways:

  • Orange - credentials information
  • Blue - endpoint access information
  • Green - resource access information
  • Red - proxy user and session user information

Some values are used to determine multiple types of access. These values initially appear as black (when they do not apply to a single type of access), and then later appear in one or more specific colors (to reflect the value is being used at that point in the process for a specific type of access).

In the following example, an API call is triggered by the Acme policy billing application, BillingApp.


Authentication flow for standalone services
  1. When BillingApp triggers an API call, it must first request a JWT from Guidewire Hub. The request for the JWT includes the client ID (0oaqt9pl1vZK1kybt0h7), the secret (aSecret), the application's API role (scp.pc.acme_billingapp), the application's resource access strategy (pc.service), and additional deployment information (tenant.acme, project.default, planet_class.prod).
  2. Guidewire Hub authenticates the services based on the client ID and secret. It also verifies that the API role and resource access strategy provided in the request match what was specified when the service was registered with Guidewire Hub.
  3. Guidewire Hub generates a JWT and sends it to the service. This JWT includes the client ID (cid) and a scp token claim which names the API role (scp.pc.acme_billingapp), the resource access strategy (pc.service), and additional deployment information.
  4. The service sends the API request to PolicyCenter along with the JWT.
  5. PolicyCenter extracts the information in the JWT into a token map. Then, the IExpandTokenPlugin plugin calls any relevant authorization applications to retrieve any relevant additional auth values that must be added to or modified in the token map. (For standalone services, there is no need for resource access IDs. But, an insurer could choose to retrieve either the API role (such as scp.pc.acme_billingapp) or the resource access strategy name (pc.service) using the IExpandTokenPlugin plugin instead of sending them in the JWT.)
  6. PolicyCenter determines the endpoint access. Based on the "scp.pc." value listed in the token map (scp.pc.acme_billingapp), the acme_billingapp.role.yaml API role file is used to define the endpoint access.
  7. Next, PolicyCenter determines the resource access strategy. Based on the resource access strategy value in the token map (pc.service), it grants resource access as defined in the service access.yaml files. (* PolicyCenter starts with service_ext-1.0.access.yaml, but this file references additional access.yaml files whose name starts with "service".)
  8. To determine which proxy user to assign to the session, PolicyCenter calls the RestAuthenticationSourceCreator plugin. The token map specified a resource access strategy of pc.service. So, the plugin returns the proxy user for services: serviceuser.
  9. PolicyCenter processes the request.
    1. The session user is the proxy service user: serviceuser.
    2. The endpoint access is defined by acme_billingapp.role.yaml.
    3. The resource access is defined by service access.yaml. In the base configuration, the service access.yaml files make all resources available. Therefore, logically speaking, there are no resource access restrictions.
  10. PolicyCenter provides the response to the initial call.