|
The settings on this tab allows you to authenticate to a Kerberos Service
by sending a Kerberos service ticket in the HTTP request to that service.
Note that it is also possible to configure the Enterprise Gateway to authenticate
to a Kerberos Service by including the relevant Kerberos tokens inside
the XML message itself. Please refer to the
Kerberos Client Authentication
help page for more information.
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. Take a
look at the Kerberos Client
help page for more information on configuring Kerberos Clients.
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 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.
Send Token with First Request
In some cases, the client may not authenticate (i.e. send the
Authorization HTTP header) to the Kerberos Service
on its first request. The Kerberos Service should then respond with
an HTTP 401 response containing a
WWW-Authenticate: Negotiate HTTP header. This
header value instructs the client to authenticate to the server by
sending up the Authorization header. The
client then sends up a second request, this time with the
Authorization header, which contains the relevant
Kerberos token. Check this option to force the
Connection filter to always send
the Authorization HTTP header that contains the
Kerberos Service ticket on its first request to the Kerberos Service.
Pass when Service Returns 200
In some (rare) cases, a Kerberos Service may return a "200 OK" response
to a Kerberos Client's initial request even though the security context
has not yet been fully established. This "200 OK" response may not
contain the WWW-authenticate HTTP header.
By checking this option, you are instructing the
Connection filter to send the request to the Kerberos
Service despite the fact that the context has not been established. The
onus then falls on the Kerberos Service to decide whether or not to
process the request depending on the status of the security context.
Send Body Only After Establish Context
The Kerberos client may be configured to only send the message body after
the context has been fully established, i.e. the client has mutually
authenticated with the service.
|