Configuring the IdP
For internal users, the IdP must store:
- The user's credentials (for example, user name and password)
For external users, the IdP must store:
- The user's credentials (for example, user name and password)
- The list of API roles that are to be granted to the user
- The user's resource access IDs
The IdP must provide this information to Guidewire Hub when it asserts the user's identity. This information is used to verify the user's identity and to determine the user's endpoint and resource access.
Configure the IdP for bearer token authentication
Procedure
-
Configure your IdP so that it knows all of the API roles that are assigned to any
external user.
- Typically, this is done with IdP groups.
- Each group name must be prefixed with
"
gwa.<planetclass>.cc.
", where<planetclass>
is set to either "prod
", "preprod
", or "lower
". - After this prefix, each group name must be identical to a system API role name.
- For example, to assign users to an API role named "Insured" for a
production planet, the IdP group must be named
"
gwa.prod.cc.Insured
".
- Configure your IdP so that every user is associated with their user credentials (such as user name and password).
- Configure your IdP so that every external user is associated with their API roles.
-
Configure your IdP so that every external user is associated with the correct
resource access IDs:
- For policy holders, this is an array of one or more policy numbers.
- For service providers, this is a single Address Book unique
identified (
gwabuid
).
-
Configure your IdP so that when a user is verified, the authorization information
is asserted using the following attribute names:
- User name is asserted as
cc_username
. - API roles are asserted as an array named groups.
- Resource access IDs for policy holders are asserted as an array named
cc_policyNumbers
. - Resource access IDs for service providers are asserted as
cc_gwabuid
.
- User name is asserted as