Oracle® Fusion Middleware
Part 11. Authentication

You can configure the API Gateway 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.

You can also configure a Connection filter (from the Routing category) to authenticate to a Kerberos Service by inserting a client-side Kerberos token into the Authorization HTTP header.

Therefore, you should use the Connection filter if you wish to send the client-side Kerberos token in an HTTP header to the Kerberos Service. You should use the Kerberos Client Authentication filter if you wish to send the client-side Kerberos token in a BinarySecurityToken block in the SOAP message. For more information on authenticating to a Kerberos Service using a client-side Kerberos token, see the topic on the Connection filter.

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

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 in this field is twofold. First, it must obtain a Kerberos Ticket Granting Ticket (TGT) 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.

Click the button on the right, and select a previously configured Kerberos Client in the tree. To add a Kerberos Client, right-click the Kerberos Clients tree node, and select Add Kerberos Client. Alternatively, you can add Kerberos Clients under the External Connections node in the Policy Studio tree view. For more details, see the Kerberos Clients topic.

Kerberos Service Principal:

The Kerberos Client selected above must obtain a service ticket from the Kerberos Ticket Granting Server (TGS) for the Kerberos Service Principal selected in this field. The Service Principal can be used to uniquely identify the Service in the Kerberos realm. The TGS grants 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 for the client to be successfully authenticated.

Click the button on the right, and select a previously configured Kerberos Principal in the tree (for example, the default HTTP/host Service Principal). To add a Kerberos Principal, right-click the Kerberos Principals tree node, and select Add Kerberos Principal. Alternatively, you can add Kerberos Principals under the External Connections node in the Policy Studio tree view. For more details, see the topic on Kerberos Principals.

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:

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.

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.

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.