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