Authentication architecture

Guidewire Hub

Guidewire Identity Federation Hub (Guidewire Hub) is the trusted auth server for all Guidewire cloud applications, including caller applications that insurers create to access Guidewire cloud resources. Guidewire Hub uses OAuth 2.0 and SAML for identity management services.

The primary responsibilities of Guidewire Hub are:

• For internal users and external users:
  • To receive authentication requests from InsuranceSuite applications and caller applications
  • To federate those authentication requests to the correct IdP
  • To construct JWTs that verify users and provide information about their authorization
• For services:
  • To authenticate services
  • To construct JWTs that verify services and provide information about their authorization

The insurer's identity provider

An identity provider (IdP) is an application or service that creates, maintains, and manages identity information for internal and external users. Every insurer using Guidewire cloud applications must provide an identity provider (IdP).

The primary responsibilities of the IdP are:

• For internal users and external users:
  • To maintain user names and passwords
  • To maintain information that identifies each user's authorization
  • To authenticate users and provide information about their authorization when a request is received from Guidewire Hub

The IdP does not play a role in service authentication or authorization.

Additional authorization applications

An additional authorization application is an application that contains additional information about the authorization of a specific caller. This additional information is not transferred in the JWT. Rather, it is retrieved by a plugin after the InsuranceSuite application has received the JWT but before authorization is determined.

There are several use cases for retrieving information from an additional authorization application, as opposed to storing it in the IdP and putting it in the JWT. This includes the following:

• The additional authorization application is the system of record for the relevant auth information. It is more efficient to retrieve this information directly from that system, as opposed to duplicating the information in the IdP.
• The size of the additional information is too large to store in a JWT. For example, if the caller is a producer, the producer's producer codes may be needed to determine their authorization. Some producers have hundreds of producer codes, and this is too much information to transfer in a JWT.

The primary responsibilities of the additional authorization application are:

• For all relevant types of callers:
  • To maintain information that identifies authorization for the relevant callers
  • To provide this information with a sufficiently rapid response time

For a given type of caller, if the amount of authorization information is small enough to be placed in a JWT, then use of an additional authorization application is possible but not required.

The caller applications

Every caller application that uses Cloud API must provide authentication information with every API call (except for unauthenticated calls).

From an authentication perspective, the primary responsibilities of each caller application are:

• For internal users and external users:
  • To send authentication requests to Guidewire Hub (which will then federate those requests to the appropriate IdP)
• For anonymous users:
  • To send unauthenticated requests to create accounts (The response to these requests includes a self-signed JWT created by PolicyCenter)
• For services:
  • To send authentication requests to Guidewire Hub (which are executed by Guidewire Hub without any involvement of the IdP)
• For all callers:
  • To temporarily store JWTs created by Guidewire Hub so that they can be included in Cloud API calls made for the associated callers
  • To temporarily store self-signed JWTs created by PolicyCenter for anonymous users so that they can be included in Cloud API calls made for those anonymous user

Cloud API

From an authentication perspective, the primary responsibilities of the Cloud API are:

• For authenticated callers:
  • Verify that each call includes valid authentication
  • Retrieve information from an additional authorization application when necessary
  • Limit the access of each call to only those endpoints, operations, fields, and specific resources that the user is authorized to use
• For unauthenticated callers:
  • Limit the access of each call to the appropriate endpoints, operations, fields, and resources
    • Typically, this access is limited to either API metadata only, or account creation for callers who will become anonymous users