Authentication options for services

Standalone service

A service can authenticate as a standalone service. In this case, the service executes the call as itself. It does not execute the call as a specific person or on behalf of a specific person. The service does not execute the call using a service account stored in PolicyCenter.

PolicyCenter designates a single internal user as the "proxy service user" for all standalone service calls. This proxy service user is attached to the standalone service session. If the call creates or modifies an object, the proxy service user is recorded as the user of record.

The primary advantage to this approach is that you need to manage authentication and authorization information at the service level only. There is no need to create and manage user accounts, user permissions, or additional mappings.

The primary disadvantage is that all standalone service calls share a single proxy service user. When a standalone service call creates or modifies an object, it may not be possible to identify which service made the call.

Service with user context

A service can authenticate with user context. In this case, the service presents information about itself. The call also includes a GW-User-Context header that provides information about a specific user. The user does not necessarily exist in the PolicyCenter database. The call is able to do only the things that both the service by itself could do and the user by itself could do.

The specified user can be an internal user (a user who is listed in the PolicyCenter database). When this is the case, this internal user is attached to the session. If the call creates or modifies an object, this internal user is recorded as the user of record.

The specified user can be an external user (a user who is not listed in the PolicyCenter database). PolicyCenter designates a single internal user as the "proxy external user" for all service with user context calls that reference external users. When the specified user is an external user, the external proxy user is attached to the session. If the call creates or modifies an object, the external proxy user is recorded as the user of record.

The primary advantage to this approach is that a single service can send calls on behalf of different users. At the service level, you can specify service-level access. But, you can also further control access for each associated user.

There are two primary disadvantages. First, you must maintain access information at two levels: the service level and at the user level. Second, a service can specify any user in its header. There is no way to restrict a given set of users for use by a given service.

Service with service account mapping

A service can authenticate with service account mapping. In this case, the service is automatically mapped to a "service account". The mapping information is specified elsewhere in the environment. The service account is a user account in the PolicyCenter database that is intended to be used only by the service and not by any person.

The primary advantage to this approach is that permissions and auditing for the call is tied to a service account that is listed in the PolicyCenter database. You can create a different service account for each service and have fine control over the permissions available to each service.

The primary disadvantage is that you must create and maintain service accounts in PolicyCenter for calls made by external applications. Also, you must maintain the mapping information that maps each service to its service account.

Comparing the different approaches

The following table compares each approach.

This topic focuses on authentication for services with user context.

• For more information on authentication for standalone services, see OAuth2 client credential flow: Standalone services.
• For more information on authentication for services with service account mapping, see OAuth2 client credential flow: Services with service account mapping.