Resource access strategies
Strategies and IDs
A resource access strategy is a set of logic that identifies which resources a caller can access.
A resource access ID is a string that identifies either who the caller is or what the caller owns.
For each call, resource access is determined by executing the resource access strategy using the resource access ID as input. For example, suppose a given resource access strategy states "the caller can access information on claims related to the policies they own". And suppose, for a given call, the resource access ID is PA-123456. This would mean the following:
- The caller can access resources that are on claims related to policy PA-123456.
- The caller cannot access resources that are on claims related to policies other than PA-123456.
Some resource access strategies require a single resource access ID. Other resource access strategies allow for an array of resource access IDs.
The list of resource access strategies
The base configuration includes the following resource access strategies:
Strategy name | Persona using this strategy | Resource access ID is... | Grants access to... |
---|---|---|---|
cc_policyNumbers | Account holders and policy holders | An array of policy numbers | Resources associated with claims associated with any of the policies. |
cc_gwabuid | Claims service provides | The ABUID (Address Book Unique IDentifier) of the service provider contact | Resources associated with any claims for which this user is an assigned service provider |
cc_username | Internal users | A ClaimCenter user name | Resources this internal user could see in ClaimCenter based on their associated Access Control Lists (ACLs). |
cc.service | Trusted service-to-service application | Not applicable | All resources |
default | Callers who have been authenticated but specify no resource access strategy with the call | Not applicable | Metadata resources only (including API schemas and typelists) |
unauthenticated | Callers who have not been authenticated | Not applicable | API schemas only |
The strategy name is used in the JWT. It appears in the scp
token claim to
identify which resource access strategy to use for the call. Also, when appropriate, it
appears as its own token claim to specify the resource access IDs.
For example, suppose that a given call is using the
cc_policyNumbers
resource access strategy with a resource access ID of
PA-123456. The JWT would include the following.
"scp": [
"cc_policyNumbers"
],
"cc_policyNumbers": [
"PA-123456"
]
Determining a call's resource access strategy
Resource access strategies are assigned by internal code as described in the following table. For calls made by services with user context, two resource access strategies are assigned, one at the service level and one at the user level. For all other types of calls, only one resource strategy is assigned.
Strategy name | This is assigned to a call when... |
---|---|
cc_policyNumbers |
Any of the following are true:
|
cc_gwabuid |
Any of the following are true:
|
cc_username |
Any of the following are true:
|
cc.service | The JWT's scp token claim contains
cc.service . |
default | The caller has been authenticated, but the JWT specifies no resource access strategy. |
unauthenticated | The caller has not been authenticated. |
The cc.service
resource access
strategy
Most of the resource access strategies specify restrictions. These resource access strategies limit what a caller can view.
However, the cc.service
resource
access strategy specifies almost no restrictions. This is because this resource access
strategy is designed to be used by services. Services are expected to be configured such
that they access only the resources appropriate for the circumstance. Consequently, JWTs for
API calls from services do not typically include resource access IDs.
Note that resource access for the different service-related auth flows behave as described here:
- For standalone services, calls use the
cc.service
resource access strategy. Therefore, they have unrestricted resource access. - For services with user context, each call's resource access is the intersection
of the service-level resource access and the user-level resource access. The
service-level resource access is the
cc.service
resource access strategy, which has no restrictions. Therefore, logically speaking, a service-with-user-context call has resource access equivalent to the user-level resource access. - For services with service account mapping, the service is mapped to an internal
service account. The
cc.service
resource access strategy is not used. Rather, the call uses thecc_username
resource access strategy.