Overview of basic authentication

Endpoint access with basic authentication

Endpoint access defines the aspects of an endpoint's behaviors that are available to a caller. This includes:

• What endpoints and resource types are available to the caller?
• What operations can a caller call on the available endpoint?
• What fields can the caller specify in a request payload or get in a response payload?

Endpoint access is controlled by API roles. An API role is a list of endpoints, operations, and fields that are available to a set of callers through API calls. API roles act as allowlists. By default, a caller has no endpoint access. When the caller is associated with one or more API roles, they gain access to the endpoints, operations, and fields allowlisted in each of those API roles.

When an internal user makes a system API call (using either basic authentication or bearer token authentication), PolicyCenter queries the operational database for this internal user's user roles. The user is given endpoint access to all API roles whose names corresponds to the names of the user's user roles.

For example, suppose that Alice Applegate is an internal user with two user roles: Underwriter and Reinsurance Manager. Alice Applegate triggers a system API call. When the API call is received, PolicyCenter queries the database for Alice's user roles. Two user roles are returned: Underwriter and Reinsurance Manager. PolicyCenter then grants Alice the endpoint access defined in the API roles named "Underwriter" and "Reinsurance Manager".

For more information on how API roles are configured, see Endpoint access.

Resource access with basic authentication

Resource access defines, for a given type of resource, which instances of that resources the caller can access. For example, suppose there is a GET /claims endpoint that is available to policyholders, underwriters, adjusters, and service vendors. All of these callers can use the endpoint to access resources whose type is claim, but each caller may be restricted so that they can access only a subset of the claims. For example:

• A policyholder may be able to see only the claims associated with the policies they hold.
• An underwriter may be able to see only the claims for policies assigned to them.
• An adjuster may be able to see only the claims assigned to them.
• A service vendor may be able to see only the claims that have a service request assigned to them.

A resource access strategy is a set of logic that identifies the meaning of a resource access ID. The base configuration includes the following resource access strategies for internal users:

When an internal user makes a system API call, the user name is used as the resource access ID. The cc_username or pc_username strategy is used automatically. This strategy consists of system API logic that matches, as closely as possible, the user's access as defined in the base configuration's Access Control Lists (ACLs).

For more information on how resource access behaves, see Resource access.

Proxy user access with basic authentication

Proxy user access is not applicable to basic authentication.