Understanding the terminology used within the Kerberos world, can be challenging. Especially when the same verbiage is used in various places to denote different meanings for different configurations. This article describes the terms "client principal" and "server principal" and how they are used in various actions in WebSphere DataPower and what they mean when they are present in the policy parameter set of a WebSphere DataPower Web services proxy.
Kerberos client and server principals – terminology
- Server principal - The Verifier principal (when used in verify/sign) or the Decryptor principal (when used in decryption/encryption)
- Client principal - The Signer Principal (when used in verify/sign) or the Encryptor principal (when used in encryption/decryption)
General concepts of Kerberos tokens
When the client signs a message and generates an AP-REQ token, it will specify who he is as the signer, as well as where the token is being sent to the verifier. Only the verifier specified in the token can verify the message.
When the server (the verifier), receives the AP-REQ, it verifies the message using the key tab file.
WebSphere DataPower implementation
WebSphere DataPower (which is the server in this example), verifies the AP-REQ token and additionally compares if the "signer principal" configured in the verify action is the same as the signer of the message. If not, it rejects the message. This feature is also available in the verify actions generated by the security policy.
When configured to use the Kerberos session key, WebSphere DataPower does not generate a new AP-REQ. Instead it generates APREQSHA1. It's the SHA1 of the Kerberos tokens and is one of the secure ways defined by the specifications to pass the Kerberos tokens. The "verifier" principal configured is not used here.
Policy parameters in Security policy
The policy parameters 'Kerberos server principal' and 'Kerberos client principal' are used as "verifier" and "signer" for the verify actions generated by the policy. For the sign actions generated in the response rule, the client and the server principal’s values are interchanged.
If you enable probe, you can view the actions generated by the policy and the tool tip for the sign and the verify actions will tell you the client and the server principals used by that action.
For example, for the sign action, though the following is specified in the policy parameter set, the sign action is generated with the client and the server principals automatically interchanged as you can see in Figure 1.
In the policy parameter set:
Client principal : Administrator@WPS.CSUPPORT.COM Server principal: HOST/126.96.36.199:2052@WPS.CUSPPORT.COM
Figure 1. Client and Server principals interchanged in the sign action generated in the response rule by the policy
The behavior explained above holds true for the other crypto actions as well (encrypt, verify and decrypt). Once we become familiar with the terms used in various places, understanding the data flow becomes much simpler. The same is true with Kerberos. This articles consolidated the various instances in which the client and server principals are referred within WebSphere DataPower. With this knowledge and with the help of probe, it will be easy to identify what values of the configured policy parameters are used by the crypto actions that are generated by the security policy.
- Comment lines by Bill Hines: "Dawn of a new (DataPower) day" (developerWorks, Nov 2009) is a step-by-step guide to exposing C++ methods as services.
- Visit the WebSphere DataPower SOA Appliance product page.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.