API Gateway in Kerberos constrained delegation

Kerberos constrained delegation (KCD) enables API Gateway to act as a trusted Kerberos service principal, acquire a Kerberos service ticket in the name of the requesting end user, and authenticate to a constrained set of Kerberos back-end services as the end user.

Client application: Does not support Kerberos authentication, or cannot provide Kerberos credentials.

API Gateway: Authenticates the client application, then acts as a Kerberos client and authenticates to the back-end service as the end user.

The client application can only authenticate using a non-Kerberos authentication mechanism. The back-end service requires Kerberos authentication, and must authenticate the real user associated with the client application.

API Gateway authenticates the client using a non-Kerberos authentication mechanism. API Gateway has no access to the end user’s Kerberos secret key or keytab. API Gateway must map the incoming user credential to the Kerberos client principal name of the user to be impersonated. To do this, API Gateway uses a selector to generate the end user's Kerberos principal name.

As a trusted proxy, API Gateway impersonates the end user's credentials and authenticates to the back-end service as the end user. The back-end service sees the request originating directly from the original end user and can authenticate the end user with Kerberos credentials. API Gateway can request Kerberos service tickets on behalf of the client to more than one Kerberos service and authenticate to multiple back-end services as the end user in a single policy.

Even when using a client application that supports Kerberos authentication, an end user may not be able to provide the Kerberos credentials, for example, when working remotely on a browser and trying to access the back-end service from outside of the Kerberos realm. Configuring API Gateway for KCD helps solve this authentication problem as well.

Note

Cross-domain authentication is not supported for Kerberos constrained delegation. However, you can configure a chain of policies with a separate Kerberos service account for each domain to overcome this.

Protocol Transition (S4U2Self) – A Kerberos service can obtain a Kerberos service ticket to itself on behalf of a Kerberos principal (the end user) without requiring the end user to initially authenticate using Kerberos. The end user can authenticate using some other authentication mechanism.

Constrained Delegation (S4U2Proxy) – A Kerberos service can request and obtain further Kerberos service tickets to other services on behalf of an end user after receiving the first Kerberos service ticket for that end user. The further Kerberos service tickets can only be requested to a constrained set of services configured in the KDC.

In API Gateway, Protocol Transition and Constrained Delegation must be used in combination. Constrained Delegation is not possible using a ticket obtained by API Gateway when authenticating the client using Kerberos. An API Gateway policy can enforce the authentication of the client to API Gateway to use Kerberos authentication. However, API Gateway does not support forcing this within Active Directory. A policy that forces the incoming authentication to use Kerberos authentication still does both Protocol Transition and Constrained Delegation.

Note

Kerberos Constrained Delegation is not supported out-of-the-box in API Gateway v7.5.1 or earlier.

In addition to constrained delegation, API Gateway also supports unconstrained or open credentials delegation. Constrained delegation is considered to be more secure than unconstrained delegation because the KDC administrator can constrain the set of back-end services that the trusted Kerberos service can request tickets for as the end user they are impersonating. Restricting the delegation reduces the number of potential targets for attacks, so that if one part of the system is compromised, the whole system is not. In unconstrained delegation, the Kerberos service ticket can be requested for any valid service. For more details, see API Gateway in unconstrained credentials delegation.

Prerequisites

Before you start configuration, you must have API Gateway installed on any machine with access to the Windows Domain Controller. The machine does not have to be a Windows machine that is part of the Windows Domain.

Example names

In this example, the trusted Kerberos principal TrustedAPIGateway can impersonate valid users in Active Directory and request service tickets in their name to the back-end service principals HTTP/BackEndService.axway.com@AXWAY.COM and HOST/BackEndService.axway.com@AXWAY.COM. You can use the example names, or replace them with names of your own.

The example Kerberos realm name AXWAY.COM is specific to the examples in this guide. Replace the example realm name with your own realm name.