Example flow for internal users

The following diagram identifies the flow of authentication and authorization information for internal users. 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 Aaron Applegate, who is an internal user, using a browser-based application.


Authentication flow for internal users

  1. When Aaron triggers an API call, the caller application must first request a JWT from Guidewire Hub. To initiate the process of getting the JWT, the caller application submits its client ID (00ubx7m33sHP1tsew7b4), the ID of the IdP (acmeIdP_ID), the application's resource access strategy (bc.username), and additional deployment information (tenant.acme, project.default, planet_class.prod).
  2. To authenticate the user, Guidewire Hub acquires the user's user name (aapplegate@acme.com) and password (aPassword) through some type of login screen. It sends this information to the appropriate IdP. The IdP authenticates the user and provides a SAML response with the user's name (aapplegate@acme.com).
  3. Guidewire Hub sends a code to the caller application. The caller application uses this code to request a JWT.
  4. Guidewire Hub generates a JWT and sends it to the caller application. This JWT includes the client ID (cid), a scp token claim which names the resource access strategy (bc_username) and additional deployment information, and a bc_username token which names the user's resource access ID (aapplegate@acme.com).
  5. The caller application sends the API request to BillingCenter along with the JWT.
  6. BillingCenter determines the endpoint access.
    1. Using the user name in the JWT (aapplegate@acme.com), BillingCenter queries for the user roles that this user has. One role is returned: BillingRep.
    2. Based on the returned role, the BillingRep.role.yaml API role file is used to define the endpoint access.
  7. Next, BillingCenter determines the resource access strategy. Based on the resource access strategy value in the JWT (bc_username), it grants resource access as defined in the internal access.yaml files. (* BillingCenter starts with internal_ext-1.0.access.yaml, but this file references additional access.yaml files whose name starts with "internal".)
  8. Proxy user access is not relevant for internal users.
  9. BillingCenter processes the request.
    1. The session user is the internal user: aapplegate@acme.com.
    2. The endpoint access is defined by BillingRep.role.yaml.
    3. The resource access is defined by internal access.yaml using the resource access ID of aapplegate@acme.com.
  10. BillingCenter provides the response to the initial call.