The API Gateway can act as a Kerberos service. In this case, Kerberos clients must obtain a Kerberos service ticket to authenticate to the Kerberos service exposed by the API Gateway. Clients must present this ticket to the API Gateway for their requests to be processed (to be successfully authenticated). The Kerberos service is responsible for consuming these tickets.
You can configure Kerberos services globally under the External Connections node in the tree view of the Policy Studio. To configure a Kerberos service, right-click the Kerberos Services node in the tree, and select the Add a Kerberos Service option from the context menu. The following sections describe how to configure the various fields on the Kerberos Service dialog.
Globally configured Kerberos services are selected by name as part of the Kerberos Service filter, which is responsible for validating the tickets consumed by the Kerberos service. Make sure to enter a descriptive name for the service in the Name field of the Kerberos Service dialog. For more information on configuring this filter, see the Kerberos service authentication topic.
Having configured the Kerberos service, it is available for selection when configuring other Kerberos-related filters. Make sure to select the Enabled check box at the bottom of the window, which is selected by default.
Complete the following fields on the Kerberos Endpoint tab:
Kerberos Principal:
Select the name of the principal to be associated with the API Gateway. Clients wishing to authenticate to the API Gateway must present a service ticket containing a matching principal name to the API Gateway.
Kerberos principals are configured globally under the External Connections node in the tree view of the Policy Studio. Right-click the Kerberos Principals node, and select the Add a Kerberos Principal option from the context menu.
Alternatively, you can select the Add button under the Kerberos Principal drop-down list to add a new principal. For more information on configuring a principal, see the Configure Kerberos principals topic.
Secret Key:
Use this section to specify the location of the Kerberos service's secret key, which is used to decrypt service tickets received from Kerberos clients.
Password:
The Kerberos service's secret key is originally created for a specific principal on the KDC. A password is required to generate this key, which can be entered directly into the Password field here.
Keytab:
Usually, however, a Keytab file is generated, which contains a mapping between a principal name and that principal's secret key. The Keytab file can then be loaded into the API Gateway configuration using the fields provided on this section.
You can load the principal-to-key mappings in the table by clicking Load Keytab, and browsing to the location of an existing Keytab file. You can add a new Keytab entry by clicking Add Principal. For more information on configuring the Keytab Entry dialog, see Kerberos Keytab concepts.
You can delete a Keytab entry by selecting the entry in the table, and clicking the Delete Entry button. You can also export the entire contents of the Keytab table by clicking the Export Keytab button.
![[Important]](../common_oracle/images/admon/important.png) |
Important |
|---|---|
|
The contents of the Keytab table (whether derived from a Keytab file or manually entered using the Keytab Entry dialog) are stored in the clear in the API Gateway's underlying configuration. The Keytab contents can be stored encrypted, if required, by setting a passphrase for the API Gateway configuration data. For more information on how to do this, see the API Gateway Administrator Guide.
When the server starts up it writes the stored Keytab contents out to
the |
Load via Native GSS Library:
If you have configured the API Gateway to Use Native GSS Library
on the instance-level Kerberos Configuration settings, you must
choose to load the Kerberos service's secret key from the location preferred
by the GSS library. The native GSS library expects the Kerberos service's secret
key to be in the system's default Keytab file. The location of this Keytab file
is specified in the default_keytab_name setting in the
krb5.conf file that the native GSS library reads using the
KRB5_CONFIG environment variable. This Keytab may contain
keys for multiple Kerberos services.
Configure the following fields on the Advanced tab:
Mechanism:
Select the mechanism used to establish a context between this Kerberos service and the Kerberos client. The Kerberos client must use the same mechanism selected here.
Extract Delegated Credentials:
A Kerberos client can set an attribute on the context with the Kerberos service to indicate that they wish to allow the service to act on behalf of the client in subsequent communications. For example, this enables the Kerberos service (the API Gateway) to assume the identity of the client when communicating with a back-end Kerberos service. In this way, the client's credentials are propagated to the back-end service as opposed to the API Gateway's credentials. This is called credential delegation.
In cases where a Kerberos client wishes to delegate its credentials to
a Kerberos service, you can configure the service to extract the
delegated credentials from the context it establishes with the client.
Select the Extract Delegated Credentials check box to
extract the client's delegated credentials and store them in the
gss.delegated.credentials and
gss.delegated.credentials.client.name message
attributes.
The extracted delegated credentials can be forwarded on to the back-end Kerberos service (on behalf of the user) using the Kerberos settings on the Kerberos Client filter or the Connection filter. When configuring the Kerberos Client used on the Kerberos Authentication tab of the Connection filter, make sure to select the option to retrieve the Ticket Granting Ticket(TGT) from the extracted delegated credentials (the Extract from delegated credentials check box on the Kerberos Endpoint tab).
For more details on configuring these options, see the following topics:
