Kerberos Client Authentication

Contents

Overview

The Enterprise Gateway can be configured to act as a Kerberos Client by obtaining a service ticket for a specific Kerberos Service. The service ticket makes up part of the Kerberos client-side token that is injected into a SOAP message and then sent to the Service. If the Service can validate the token the client will be authenticated successfully.

It is also possible to configure a Connection filter (from the Routing category of filters) to authenticate to a Kerberos Service by inserting a client-side Kerberos token into the Authorization HTTP header.

Therefore, the Connection filter should be used if you want to send the client-side Kerberos token in an HTTP header to the Kerberos Service, while the Kerberos Client Authentication filter should be used if you want to send the client-side Kerberos token in a BinarySecurityToken block within the SOAP message. Please refer to the Connection filter help page for more information on authenticating to a Kerberos Service using a client-side Kerberos token.

The Kerberos Client Authentication filter is available from the Authentication category of filters. Drag and drop this filter on to the Policy Editor to configure this filter. The sections below describe how to configure the fields on this filter screen.

Kerberos Client

The fields configured on this tab determine how the Kerberos Client obtains a service ticket for a specific Kerberos Service. The following fields must be configured:

Kerberos Client:
The role of the Kerberos Client selected here is twofold: first, it must obtain a Kerberos TGT (Ticket Granting Ticket) and second, it uses this TGT to obtain a service ticket for the Kerberos Service Principal selected below. The TGT is acquired at server startup, refresh (for example, when a configuration update is deployed), and when the TGT expires. For more details on configuring Kerberos Clients, see Kerberos Client.

Kerberos Clients are configured globally under the "External Connections" node in the tree view of the Policy Studio. They can then be selected in the Kerberos Client dropdown on this tab. It is also possible to add a global Kerberos Client directly from this tab by clicking the Add button. Similarly, existing Kerberos Clients can be edited and deleted by selecting the client in the dropdown and clicking the Edit and Delete buttons, respectively.

Kerberos Service Principal:
The Kerberos Client selected from the dropdown above must obtain a service ticket from the Kerberos TGS (Ticket Granting Server) for the Kerberos Service Principal selected here. The Service Principal can be used to uniquely identify the Service within the Kerberos realm. The TGS will grant a ticket for the selected Principal, which the client can then send to the Kerberos Service. The Principal in the ticket must match the Kerberos Service's Principal in order for the client to be successfully authenticated.

Kerberos Principals are also configured globally under the "External Connections" node in the tree view of the Policy Studio. Alternatively, it is possible to add a global Kerberos Principal directly by clicking the Add button. Existing Kerberos Principals can be edited and deleted by clicking the Edit and Delete buttons, respectively. For more information on configuring Kerberos Principals please refer to the Kerberos Principals help page.

Kerberos Standard:
When using the Kerberos Client Authentication filter to insert Kerberos tokens into SOAP messages in order to authenticate to Kerberos Services, it can do so according to 2 different standards:

  • Web Services Security Kerberos Token Profile 1.1
  • WS-Trust for Simple and Protected Negotiation Protocol (SPNEGO)

When using the Kerberos Token Profile, the client-side Kerberos token is inserted into a BinarySecurityToken block within the SOAP message. The Kerberos session key may be used to sign and encrypt the SOAP message using the signing and encrypting filters. When this option is selected, the fields on the Kerberos Token Profile tab must be configured.

When the WS-Trust for SPNEGO standard is used, a series of requests and responses occur between the Kerberos Client and the Kerberos Service in order to establish a secure context. Once the secure context has been established (using WS-Trust and WS-SecureConversation), a further series of requests and responses are used to produce a shared secret key that can be used to sign and encrypt "real" requests to the Kerberos Service.

If the WS-Trust for SPNEGO option is selected it will not be necessary to configure the fields on the Kerberos Token Profile tab. However, the Kerberos Client Authentication filter must be configured as part of a complicated policy that is set up to handle the multiple request and response messages that are involved in setting up the secure context between the Kerberos Client and Service.

Kerberos Token Profile

The fields on this tab need only be configured if the Kerberos Token Profile option has been selected on the Kerberos Client tab. This tab allows you to configure where to insert the BinarySecurityToken within the SOAP message.

Where to Place BinarySecurityToken:
It is possible to insert the BinarySecurityToken inside a named WS-Security Actor/Role within the SOAP message or else an XPath expression can be specified to indicate where the token should be inserted.

Select the WS-Security Element radio button if you wish to insert the token into a WS-Security element within the SOAP Header element. You can either select the default "Current actor/role only" option from the dropdown or enter a named actor/role in the field provided. The BinarySecurityToken will be inserted into a WS-Security block for the actor/role specified here.

Alternatively, you should select the XPath Location option if you want to use an XPath expression to specify where the BinarySecurityToken is to be inserted. Click the Add button to add a new XPath expression or select an XPath and click the Edit or Delete buttons to edit or delete an existing XPath expression. Take a look at the Configuring XPath Expressions help page for more information on how to configure XPath expressions.

Note that it is possible to insert the BinarySecurityToken before or after the node pointed to by the XPath expression. Select either the Append or Before radio buttons depending on where you want to insert the token relative to the node pointed to by the XPath expression.

BinarySecurityToken Value Type:
Currently, the only supported BinarySecurityToken type is the "GSS_Kerberosv5_AP_REQ" type. The selected type will be specified in the generated BinarySecurityToken.