Where do authorization values come from?
For every caller, you need to store a value that determines the caller's endpoint access. This value determines which endpoints and operations the caller can use. For some callers, you must also store values that determine the caller's resource access. These values determine which specific instances of a given resource the caller can view or edit. These are collectively referred to here as authorization values.
The IdP
For some auth flows, authorization values must come from the IdP, or otherwise accessible to the IdP so that they can be included in the IdP's SAML response. The following Cloud API auth flows support this:
- Internal user
- External user
The caller application itself
For other auth flows, authorization values must come from the caller application itself, of otherwise accessible to it. The following Cloud API auth flows support this:
- Standalone service
- Service with internal user context
- Service with external user context
The Guidewire configuration
For the service with service account mapping auth flow, the caller application provides a client ID. This ID is mapped to a service account, and this service account is used to determine the authorization values. For this auth flow, the authorization values come from the mapping information, which is stored in the Guidewire configuration itself.
Summary of behaviors
The following table summarizes these behaviors.
| Internal User | External User | Standalone service | Service with Internal User Context | Service with External User Context | Service with Service Account Mapping | |
|---|---|---|---|---|---|---|
| Where do authorization values come from? | The IdP | The IdP |
The service itself (endpoint access values only; resource access IDs are not applicable) |
The service itself | The service itself | The Guidewire configuration |
For a summary of all the issues to consider in a single table, see Summary of the issues to consider.