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:
-
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.
|