Config Ws DP Kerberos Gui2

Configuring a WebSphere DataPower Kerberossecured backend server, Part 2: Using a DataPower
custom stylesheet for client user ID authentication

Bill Barrus (bbarrus@us.ibm.com)
Senior Solutions Architect
IBM
30 October 2013
Michael McMahon (mmcmaho@us.ibm.com)

Advisory Software Engineer
IBM
Krithika Prakash (krithika@ca.ibm.com)
Advisory Software Engineer
IBM
This 2-part article series de-mystifies the work required to set up a WebSphere DataPower
configuration that uses a Kerberos-secured backend server. The first article describes how
to create these configurations in a static fashion using the DataPower Web Graphical User
Interface. This second article describes how to dynamically generate Kerberos tokens using the
DataPower customer stylesheet dp:get-kerberos-apreq method so that all of the client requests
are sent to the web application using the end client Kerberos user ID.
View more content in this series
Introduction
In this second of this 2-part series, you will again work with a solution that has a set of clients that
need to connect to a web application on the backend server. This web application, the sample
"snoop" application, is still secured by Kerberos authentication. Also similar to the scenario in the
first article, the incoming clients are not authenticated in DataPower via Kerberos. Instead, basic
authentication and a Lightweight Directory Access Protocol (LDAP) server are used to authenticate
to the DataPower appliance.
For this new scenario, you will setup a Multi-Protocol Gateway (MPGW) to accept incoming client
requests as HTTP GET requests, authenticate and authorize the clients based on their incoming
credentials, and then submit the client requests to the backend server using a Kerberos token to
authenticate with the backend server. This is similar to what was done in the first article. In this
Copyright IBM Corporation 2013
Configuring a WebSphere DataPower Kerberos-secured backend
server, Part 2: Using a DataPower custom stylesheet for client
user ID authentication
Trademarks
Page 1 of 31
developerWorks
ibm.com/developerWorks/
scenario, however, you will use a more dynamic approach to create the Kerberos ticket. A sample
DataPower configuration and a sample custom stylesheet are provided in the Downloads section
of this article.
Note that DataPower V6.0.0 supports constrained Kerberos delegation. This article does not
describe that feature.
Scenario from the previous article

The last article discussed the steps needed to set up a Kerberos configuration in DataPower in
a static fashion using the DataPower Web Graphical User Interface. We described how to create
a Multi-Protocol Gateway (MPGW) configuration that allowed incoming clients to access a web
application on a customer's backend server. The application on the backend server was secured
via Kerberos authentication. In that static DataPower configuration, all of the client requests
were first authenticated and authorized by DataPower by extracting the credentials from the
incoming HTTP Basic Authentication Header and verifying them against a Lightweight Directory
Access Protocol (LDAP) server. These client requests were then forwarded to the backend server
application after DataPower injected a Kerberos ticket into the request. In this static configuration,
the Kerberos ticket was generated using the single DataPower ID registered on the KDC. The
actual client user ID was not used to generate the Kerberos ticket in this scenario.
As was mentioned in the first article, sending all user requests to the backend server under a
single Kerberos user ID is perfectly fine if the the backend web application does not need to obtain
the originating client user ID from the Kerberos token. In the static configuration scenario, the
client has passed the authentication and authorization screening and is, therefore, considered a
legitimate user to access the web application.
If the client user ID was required in this solution, it could have been passed into the backend
server through other potential techniques, such as using a HTTP request parameter or a SOAP
element. However, there may be other solutions with a requirement for the client ID to be passed
to the backend application via the Kerberos ticket. In this article, we will address this scenario and
demonstrate how to use custom stylesheets to dynamically create a Kerberos ticket with the client
ID.
Dynamic solution scenario

The scenario that you will work with in this second article has a set of clients that need to connect
to a web application on the customer's backend server. This web application, the sample "snoop"
application, is still secured by Kerberos authentication. Also similar to the scenario in the first
article, the incoming clients are not authenticated in DataPower via Kerberos. Instead, basic
authentication and a Lightweight Directory Access Protocol (LDAP) are used to authenticate to our
DataPower appliance.
For this new scenario, we will set up a Multi-Protocol Gateway (MPGW) to accept incoming client
requests as HTTP GET requests, authenticate and authorize the clients based on their incoming
credentials, and then submit the client requests to the backend server using a Kerberos token to
Page 2 of 31
developerWorks
authenticate with the backend server. This is similar to what was done in the first article. In this
second scenario, however, you will use a dynamic approach to create the Kerberos ticket.
Kerberos interaction in this dynamic scenario

The DataPower MPGW in the first article was configured to use a static Client Keytab file that
allowed DataPower to generate Kerberos tickets using the Kerberos user ID defined in that keytab
file. Because of this, all of the client requests were mapped to a single Kerberos ID, which used
to be Kerberos Principal name for DataPower that is configured in the KDC. This required the
authorization filtering steps to be performed in DataPower before allowing a client to access the
web application. The backend server did not receive the actual client user ID.
In the new scenario, you will configure the DataPower MPGW to generate a Kerberos ticket using
the actual client ID as the Kerberos principal name. To do this, the MPGW extracts the client
ID and password from the basic authentication credentials. The user ID and password are also
stored in the domain's Active Directory (AD) database and the password serves as the secret
key by the Key Distribution Center (KDC) when it generates Kerberos tokens. This is the same
secret key that is stored in a keytab file when a keytab file is generated for a Service Principal
Name (SPN). Therefore, DataPower communicates with the Key Distribution Center (KDC) and
requests a service ticket from the KDC for a given client ID using the extracted password. One
key requirement for this new approach is the need for all the clients to have an ID (Principal) in the
Kerberos KDC realm. This was not a requirement in the first article.
An overview of this dynamic approach is shown in Figure 1.
Figure 1. Overview of the dynamic solution scenario
An advantage of this approach is that a Kerberos keytab file does not need to be imported into the
DataPower MPGW configuration. Since access to the secret key is achieved dynamically by the
extracting it from the incoming client request, it does not need to be extracted from a pre-imported,
static keytab file. This helps to simplify the Kerberos keytab administration.
Page 3 of 31
developerWorks
A disadvantage to this approach is that it requires a more complicated, programmatic

configuration. A DataPower extension function is needed to communicate with the KDC, pass in
the required parameters, and request or receive a service ticket.
The good news is that even though this MPGW configuration requires a programmatic approach,
the custom XLST transform is not difficult to write or understand. There is a good reference manual
that provides details on the various extension functions and example snippets showing how the
extension functions are used. This reference was initially produced for version 3.8.1 of DataPower,
but it is still a useful guide in understanding how to write XSLT stylesheets.
Another notable disadvantage to this approach, as we inferred earlier, is the need to ensure that
every client has an ID in the KDC realm. In a Windows Active Directory (AD) environment, as
used in this scenario, this may not be a significant disadvantage if all users already exist in the
AD. The Microsoft KDC uses the AD directory database, so there is not an extra step needed to
ensure that the KDC has the user Principal. In other types of Kerberos environments, this may not
be as easy to administer.
Kerberos and domain controller tasks

You do not need to create a client Service Principal Name (SPN), as required in the first article.
You will, instead, use the User Principal Names (UPN) that are associated with all of the Active
Directory (AD) user accounts. These same userids are then used for both LDAP authentication
and for identity in the Kerberos tickets.
Create Active Directory client accounts

For our sample scenario, you will create two client IDs in the AD repository. Typically, you either
expect that these IDs already exist in the directory, or you have to create user IDs for all the clients
that will be accessing the web application through DataPower.
1. Set up the first client user ID in the AD. In the AD Users console, right-click the Users folder
and choose New > User. Enter democlient1 in the "Full name" field and in the "User logon
name" field. Click the Next button, as shown in Figure 2.

Page 4 of 31
developerWorks
Figure 2. New AD user
2. Enter a password for this account and uncheck the User must change password at next
logon checkbox and check the User cannot change password and Password never
expires checkboxes, as shown in Figure 3. Click the Next button.
Figure 3. New AD user options
3. Click the Finish button to complete the creation of this new user account. Set up the second
client user ID in the AD. Perform the instructions in Steps 1 through 3, but use democlient2
for the "Full name" field and "User logon name" field.
Now run a Windows OS based utility command on the Domain Controller server to view the
attributes related to the newly created user IDs to verify the value of the UPN stored in the

Page 5 of 31
developerWorks
AD. The command exports the objects from the AD repository and writes them to a specified
file.
4. Open a DOS command window on the Domain controller machine and issue the following
command (substitute your appropriate base distinguished name, "DC=support,DC=com" for the
one shown below. See Figure 4.
ldifde -f c:\temp\ldapData.txt -d "DC=csupport,DC=com" -l *,msDS-KeyVersionNumber -r "(displayName=*)"
Figure 4. ldifde command execution
5. Open the c:\temp\ldapData.txt file and search for the new "demoClient1" user ID that was
created in Step 2. You see "userPrincipalName" for this user ID. This is the UPN value you
will use when you create the client Kerberos ticket in DataPower. See Figure 5.

Page 6 of 31
developerWorks
Figure 5. demoClient1 AD attributes
Kerberos keytab file server application

The only other task that you will perform on the Domain Controller is to verify that the SPN for the
backend server application that exists in the KDC. On WebSphere Application Server, where the
snoop application is hosted, the administrator has already set up a user ID and an SPN to be used
as the Server SPN. The administrator also created a keytab file for that server SPN account. This
keytab file is uploaded to Application Server to allow the decryption of service tickets that are sent
to it.
As was the case in the first article, you need to obtain this SPN value (HTTP/
oc4102831681.csupport.com is the SPN for the demo solution) that was set up for Application
Server. Once you find out what the user ID account name is associated with the server SPN, you
can issue the following command to verify that this account is still active:
setspn -l <userid associated with the server application SPN>
You see the following type of output from this command. In our example, the account name for the
server SPN, HTTP/oc4102831681.csupport.com, is "waskerb".
Registered ServicePrincipalNames for CN=waskerb,CN=Users,DC=csupport,DC=com:HTTP/oc4102831681.csupport.com

Page 7 of 31
developerWorks
DataPower related tasks

You can create a Multi-Protocol Gateway (MPGW) configuration that allows your clients to connect
to your backend web application (the snoop application) using a Kerberos ticket associated with
the client's UPN. In this configuration, clients will submit HTTP GET requests to DataPower with
a basic authentication string that contains the client user ID and password. DataPower accepts a
client request, authenticate the user in LDAP, and creates a Kerberos ticket based on the client's
UPN. This Kerberos ticket authenticates the backend server and provides access to the snoop
application. The response from the snoop application is passed back to the client. Since the client
user ID is passed in the Kerberos ticket, the snoop application can generate information that
identifies the name of the actual end client. This is a key difference from the first article where the
principal name displayed in the snoop output was always the name associated with the single
client keytab file that is statically configured in DataPower.
Create the Multi-Protocol Gateway

1. Log into the DataPower console. In the "default" domain, create a new application domain
called kerbDemo. If you have already completed the DataPower configuration for the first
article of this series, you should already have a kerbDemo domain and do not need to create
this domain.
2. Switch to this new kerbDemo domain and click on the Multi-Protocol Gateway (MPGW) icon.
3. In the MPGW panel, click the Add button. Create a new MPGW configuration called
kerbDemo2MPG by typing this into the "Multi-Protocol Gateway Name" field. Leave the "Type"
field set to static-backend.
Define the front side handler settings

Define a front side handler to accept a HTTP GET requests on port "50008" (this is an arbitrary
port we have selected for incoming requests), and ignore all requests except those targeted for the
"snoop" application.
1. Click the "+" button and then select HTTP Front Side Handler in the combo list in the "Front
Side Protocol" section on the lower right side of the MPGW panel, as shown in Figure 6.
Figure 6. Selecting the Front Side Protocol Handler type

Page 8 of 31
developerWorks
2. In the resulting "Configure HTTP Front Side Handler" panel, type in kerbDemo2FSH in the
"Name" field, type 50008 for the "Port Number" field, and check the GET method checkbox
below, as shown in Figure 7. Leave all the other fields alone and click the Apply button.
Figure 7. Front Side Handler settings
3. Finally, under the "Request Type" sub-section of the "Front side settings" section, click the
Non-XML radio button as your clients will not be sending SOAP or XML to DataPower. Leave
all the other fields or attributes set to their defaults.
Define the back side settings

1. For the back side settings, enter the URL required to access the WebSphere Application
Server snoop application. In our case, it was http://9.42.90.238:11000/snoop.
2. Under the "Response Type" sub-section of the "Back side settings" section, click the NonXML radio button as the snoop application simply sends back a response in HTML format.
Leave all the other fields or attributes set to their defaults. See Figure 8 for the final Back side
and Front side settings.

Page 9 of 31
developerWorks
Figure 8. Back side and front side settings
Define the Multi-Protocol Gateway policy

Similar to the first article, you will now define the MPGW Policy. The policy authenticates
the incoming clients against the LDAP server using the client provided basic authentication
credentials. As part of this policy, however, you will be writing and using a custom XSLT stylesheet
transform object that is invoked each time a client request is processed. This stylesheet uses
one of the DataPower provided XSLT functions to make a call to the KDC server and creates a
Kerberos ticket, using the client's user ID and password credentials that were passed in with the
client's basic authentication string. This allows DataPower to propagate the actual client's user ID
to the backend server in the Kerberos ticket.
1. Click the "+" sign under the "Multi-Protocol Gateway Policy" section of your kerbDemo2MPG
configuration to create a new MPGW Policy for this configuration.
2. In the "Configure Multi-Protocol Gateway Style Policy" panel, enter kerbDemo2MPGPolicy for
the "Policy Name" field.
3. Under the Rule section, select Client to Server for the "Rule Direction". Then click the New
Rule button. Your policy now looks similar to what is shown in Figure 9.

Page 10 of 31
developerWorks
Figure 9. Initial MPGW Policy panel
4. Double-click on the Match action (the diamond with an equal sign in the middle) and create
a "Matching Rule" that matches all incoming client requests that are directed for the snoop
application.
5. Click the "+" sign next to "Matching Rule" combo box.
6. In the resulting "Configure Matching Rule" panel, while in the Main tab, enter
kerbDemo2SnoopMatch for the Name field, as shown in Figure 10.

Page 11 of 31
developerWorks
Figure 10. Configure the matching rule name
7. Click on the Matching Rule tab of the "Configure Matching Rule" panel. Click on the Add
button to create a new matching rule. Leave "Matching Type" set to URL and enter /snoop for
the "URL Match" value, as shown in Figure 11.
Figure 11. Create a matching rule
8. Click Apply to save these changes. Click Apply again in the "Configure Matching Rule"
panel. Click Done in the "Configure a Match Action" panel to update this new matching rule.
See Figure 12.

Page 12 of 31
developerWorks
Figure 12. Configure matching action
Define an AAA action

Now create your security action where you will be writing your custom XSLT transform code. You
will first step through the preliminary panels that are a part of the AAA action to configure the
authentication and authorization behavior for the incoming client requests.
1. From the "Create rule:" section of the "Configure Multi-Protocol Gateway Style Policy" panel,
click on the AAA icon and drag it to the rule line, as shown in Figure 13.
Figure 13. Drag AAA onto the rule line
2. Double-click on the newly positioned AAA icon to configure the AAA actions. On the resulting
"Configure AAA Action" panel, first change the "Input" selection from (auto) to INPUT. Next
change the "Output" value from (auto) to OUTPUT, as shown in Figure 14.

Page 13 of 31
developerWorks
Figure 14. Input and output settings
3. Click on the "+" to the left of the "AAA policy" combo box to create a new AAA Policy object,
as shown in Figure 15.
Figure 15. AAA Policy Add button
4. In the "Configure an Access Control Policy" panel, enter kerbDemo2AAAPolicy and click the
Create button.
5. On the next panel, check the HTTP Authentication Header checkbox under the "Define how
to extract a user's identity ..." section as shown in Figure 16. Click the Next button.

Page 14 of 31
developerWorks
Figure 16. AAA Policy Add button
6. Under the "Define how to authenticate the user" section of the next panel, check the Bind to
Specified LDAP Server checkbox, as shown in Figure 17.
Figure 17. Bind to specified LDAP server selection
7. Additional LDAP-related configuration fields are added to the panel. Fill in these values as
shown below:
LDAP Load Balancer Group: <load balancer group of LDAP servers; default is "none">
Host: <ip address or host name of LDAP server>
Port: <LDAP port; default value is "389">
SSL Proxy Profile: <name of ssl proxy profile; default is "none">
LDAP Bind DN: <bind Distinguished Name (DN) that has permission to search LDAP directory>
LDAP Bind Password: <bind DN password>
LDAP Search Attribute: <default is "dn">
LDAP Version: <default is "v2">
LDAP Search for DN: <default is "off">
LDAP Prefix: <String prepended to username to form a DN to search for, default is "cn=">
LDAP Suffix: <default is blank field>
Use Auxiliary LDAP Attributes: <default is none>
8. Once these values are appropriately filled in to match your LDAP environment, click the
Next button. In this demo scenario, the incoming user ID and password were used to bind
to the LDAP server and authenticate the user, so only the LDAP IP address and port were
required (everything else was defaulted). This is a very simplified configuration. You will need

Page 15 of 31
developerWorks
to configure your LDAP server in a way that is appropriate for your security environment. See
Figure 18.
9. One important clarification to mention here is that, since you will be authenticating the user
ID and password as part of the Kerberos ticket generation, this step of authenticating with
the LDAP server is redundant. We have included this step as an example of how to perform
LDAP authentication, but it is not a necessary step for this scenario.
Figure 18. LDAP server settings
10. Click the Next button. On the "Define how to extract the resources" section of the next panel,
click the URL sent to backend checkbox as shown in Figure 19, and click the Next button.
Figure 19. Define how to extract the resources
11. On the "Define how to authorize a request" section of the next panel, leave the default radio
button selection set for the Allow any authenticated client option, as shown in Figure 20.
This indicates that any client that is successfully authenticated is authorized to access the
backend server. Click the Next button.

Page 16 of 31
developerWorks
Figure 20. Define how to authorize a request
On the final panel of the AAA Access Control Policy, you will configure the policy to use a
custom XSLT processing stylesheet. In this stylesheet, you will write code to programmatically
perform the following processing steps:
a. Extract the user ID and password from the incoming basic authentication credentials and
place these values in variables.
b. Populate two variables with the Server SPN (SPN is the backend web application, which
has to be hardcoded), and the Client SPN, using the incoming user ID (UPN) as part of
the Client SPN.
c. Generate a Kerberos token by calling the DataPower provided dp:get-kerberos-apreq()
extension function. The Client SPN, the client password (this is also the client's secret
key from the KDC's perspective), and the Server SPN is used as parameters for this
function call. The returned token from the KDC contains the incoming client user ID since
you specified the UPN for your token request.
Note: In this example, we are also setting an optional parameter for the dp:get-kerberosapreq() method to turn on the "generateGssChecksum" option. This forces a checksum
to be generated for the Kerberos token. This checksum is required if interacting with
more current versions of WebSphere Application Server.
d. Populate a variable to hold the value of the Kerberos token. Extract the necessary string
from the token returned from the previous dp:get-kerberos-apreq() call to populate this
variable.
e. Add this header as an "Authorization" header to the outgoing request to the backend
server.
When the client request is sent to the backend server, it contains a Kerberos token associated
with the actual client user ID. This allows the backend server to authenticate the Kerberos
token and identifies the user who made the request. As mentioned before, this is different
from the first article of the series, where all the requests are sent to the backend server with
one common or shared user ID (user ID associated with the Client keytab file imported into
DataPower).
12. Create a new file called kerbDemo2Custom.xsl. Add the code shown in Listing 1 to the
file and save this file to a temporary directory. You are looking at the Probe data later in this
article to get more clarification on the logic in this stylesheet.
Page 17 of 31
developerWorks
Listing 1. KerbDemo2Custom.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dp="http://www.datapower.com/extensions"
extension-element-prefixes="dp">
<xsl:output method="xml"/>
<xsl:template match="/">

<xsl:variable name="userid">
<xsl:value-of select="dp:auth-info('basic-auth-name')"/>
</xsl:variable>
<xsl:variable name="pwd">
<xsl:value-of select="dp:auth-info('basic-auth-password')"/>
</xsl:variable>

<xsl:variable name="kerb_client_spn" select="concat($userid,'@CSUPPORT.COM')" />
<xsl:variable name="kerb_server_spn" select="'HTTP/oc4102831681.csupport.com@CSUPPORT.COM'" />

<xsl:variable name="options">
<options GenerateGssChecksum="on" GssChecksumFlags="REPLAY+SEQUENCE+CONF+INTEG"
RequestForwardableTicket="on"/>
</xsl:variable>

<xsl:variable name="kerb_apreq" select="dp:kerberos-get-apreq($kerb_client_spn,concat
('password:', $pwd), $kerb_server_spn, $options)"/>

<xsl:variable name="kerb_apreq_base64">
<xsl:value-of select="concat('Negotiate ',$kerb_apreq/apreq/spnego-apreq-base64)"/>
</xsl:variable>

<dp:set-http-request-header name="'Authorization'" value="$kerb_apreq_base64"/>

Page 18 of 31
developerWorks
</xsl:template>
</xsl:stylesheet>
13. Under the "Choose any post processing" section of this panel, click the on radio button for the
"Run Custom Post Processing Stylesheet" option. Then click the Upload button as shown in
Figure 21.
Figure 21. Run Custom Post Processing Stylesheet section
14. In the "Upload File to Directory" panel, browse to the directory where the
"kerbDemo2Custom.xsl" resides, highlight it, click Open, and click the Upload button. See
Figure 22.
Figure 22. Upload XSL file dialog
15. Click the Commit button to submit and apply this configuration.
16. Click on the Done button on the "Configure an Access Control Policy" panel, click Done on
the "Configure AAA Action" panel, and then click the Apply Policy button on the "Configure
Multi-Protocol Gateway Style Policy" panel. Then click the Close Window link on the
"Configure Multi-Protocol Gateway Style Policy" panel (upper right-hand section of the panel)
to close this panel and return to the main DataPower console panel, as shown in Figure 23.

Page 19 of 31
developerWorks
Figure 23. Applying and closing the MPGW Style Policy
17. On the main "Configure Multi-Protocol Gateway" panel, click the Apply button to commit
these changes and then save this configuration, as shown in Figure 24. You are almost ready
to test the new configuration.

Page 20 of 31
developerWorks
Figure 24. Applying and closing the MPGW Style Policy
Configuring the Kerberos KDC server object on DataPower

Like the demo scenario in the first article of this series, this step is required. If not already done,
you need to configure a KDC server for communication with DataPower.
1. On the left side of the panel, expand the Objects folder and then expand the Crypto
Configuration folder. Click on the Kerberos KDC Server object, as shown in Figure 25.

Page 21 of 31
developerWorks
Figure 25. Kerberos KDC Server under the crypto configuration
2. In the "Configure Kerberos KDC Server" panel, click the Add button to add a new KDC server
entry. Enter a name for your KDC server (this can be anything meaningful to you) and then
enter the realm name in the "Kerberos realm name" field and the host name or IP address of
the KDC server in the "Kerberos KDC Server" field. You can click the Ping Remote button to
ensure that you can contact the KDC server.
Note: The Kerberos realm name must match the realm name used in the client and server
SPN values defined earlier in your AAA Post Processing action, such as "CSUPPORT.COM".
Case sensitivity is important.
3. To prevent possible errors related to the Kerberos token sizes, turn on the Use TCP radio
button. The "Server Port Number" field typically remains as the default value (88). Click the
Apply button to create this new KDC Server object, as shown in Figure 26. Finally, save the
configuration.

Page 22 of 31
developerWorks
Figure 26. Configure the Kerberos KDC Server
Testing the dynamic scenario

You are now at the stage where you can test the MGP configuration and ensure that the client
making the request through DataPower can connect to the backend server with the dynamically
generated Kerberos service ticket. As in the first article, you again use the "curl" utility to submit
the test requests to DataPower. You use the exact same command used in the first article, but you
use the port number associated with this new MPGW configuration instead. You also issue the
command using the two user IDs that were setup in the Create Active Directory Client Accounts
section.
1. Issue the following curl command to simulate a client browser sending a request to
DataPower to access the backend snoop application. The sample results are shown in Listing
2.
curl -v --basic -u "democlient1:d3m0Passw0rd" http://9.42.125.176:50008/snoop
Listing 2. Sample results from the curl command to test the Kerberos
configuration
curl -v --basic -u "democlient1:d3m0Passw0rd" http://9.42.125.176:50008/snoop
* About to connect() to 9.42.125.176 port 50008 (#0)
*
Trying 9.42.125.176... connected
* Connected to 9.42.125.176 (9.42.125.176) port 50008 (#0)
* Server auth using Basic with user 'democlient1'
> GET /snoop HTTP/1.1
> Authorization: Basic ZGVtb2NsaWVudDE6ZDNtMFBhc3N3MHJk
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18

Page 23 of 31
developerWorks
libssh2/1.4.2
Host: 9.42.125.176:50008
Accept: */*
>
>
>
<
<
<
<
<
HTTP/1.1 200 OK
X-Backside-Transport: OK OK
Connection: Keep-Alive
Transfer-Encoding: chunked
WWW-Authenticate: Negotiate oT0wO6ADCgEAoQsGCSqGSIb3EgECAqMnBCVgIwYJKoZIhvcSAQICAQERAP/////
VzFR7ke/rP5A/+RIL7+bo
...
...
...
<tr><td>Server name</td><td>9.42.90.238</td></tr>
<tr><td>Server port</td><td>11000</td></tr>
<tr><td>Remote user</td><td>CN=democlient1,CN=Users,DC=csupport,DC=com</td></tr>
<tr><td>Remote address</td><td>9.42.125.176</td></tr>
<tr><td>Remote host</td><td>DPL2XG1.rtp.raleigh.ibm.com</td></tr>
<tr><td>Remote port</td><td>48559</td></tr>
<tr><td>Local address</td><td>9.42.90.238</td></tr>
<tr><td>Local host</td><td>oc4102831681.csupport.com</td></tr>
<tr><td>com.ibm.websphere.servlet.application.host</td><td>server1</td>
</tr><tr><td>com.ibm.websphere.servlet.application.name</td><td>Default Web Application</td></tr>
<tr><td>com.ibm.ws.webcontainer.config.WelcomeFileList</td><td>[index.html]</td>
</tr>
<tr><td>com.ibm.websphere.servlet.enterprise.application.name</td><td>DefaultApplication
</td></tr>
<tr><td>javax.servlet.context.tempdir</td><td>/opt/ibm/SDP/runtimes/base_v7/profiles/
WTE_APPSRV71/temp/localhostNode01/server1/DefaultApplication/DefaultWebApplication.war</td></tr>
<tr><td>com.ibm.websphere.servlet.event.ServletContextEventSource</td><td>
com.ibm.ws.webcontainer.webapp.WebAppEventSource@66646664</td></tr>
<tr><td>com.ibm.wsspi.portletcontainer</td><td>com.ibm.ws.portletcontainer.pcinvoker.
PortletContainerImpl@6a5c6a5c</td></tr>
</table><BR><BR>
</body></html>
* Connection #0 to host 9.42.125.176 left intact
* Closing connection #0
If this HTML content from the response is opened with a browser, it appears similar to Figure
27. As you can see in this response data, the "Remote user" value is set to value of the client
who made the request. This is a key difference from the scenario in the first article, where the
"Remote user" value was always the user ID associated with the client keytab file that was
imported into DataPower.

Page 24 of 31
developerWorks
Figure 27. Snoop application response with client user ID
Probe analysis
To help clarify what is going on in the custom stylesheet logic, you can enable the DataPower
Probe for this MPGW configuration as was discussed in the previous article. After you do this and
run a test, you can review the probe output and click on the AAA icon. You see something similar
to Figure 28.
Figure 28. AAA Probe execution trace
If you click on the (show nodeset) link on this panel, you can view the full <apreq> element that is
generated by dp:get-kerberos-apreq function that you called in your custom stylesheet. Observe
that the <spnego-apreq-base64> sub-element within this token. This is the information that your
custom stylesheet extracts from the token and places into a temporary variable. See Figure 29.
Page 25 of 31
developerWorks
Figure 29. Generated Kerberos token
Finally, if you go back to the Probe panel and click on the magnifying glass icon that is located
after the AAA action icon, and then click on the Headers tab of the resulting panel, you see the
"Authorization" header is one of the headers included in the HTTP request. This is the header that
was inserted by your custom stylesheet. Also notice the value of this header contains "Negotiate",
followed by a string from the "<spnego-apreq-base64>" sub-element. This matches the logic in the
stylesheet. See Figure 30. Hopefully, this review helps to reinforce your understanding of the logic
in your custom stylesheet.

Page 26 of 31
developerWorks
Figure 30. HTTP Authorization header
Troubleshooting tips
In addition to the troubleshooting tips from the first article, there are a few additional problems that
you may encounter when developing this solution that uses a custom XSLT stylesheet.
Table 1. Troubleshooting tips

Problem
Symptom
Resolution
Invalid user ID is used by the client in

the Basic Authentication string when
submitting requests to DataPower.
Debug the level messages seen in the

DataPower error log:
mpgw (kerbDemo2MPG):
anyauthenticated authorization
failed with credential 'SPECIALFORMAT-NOT-PRINTED' for resource
'/snoop'
Client principal
'democlient3@CSUPPORT.COM' not
found in Kerberos KDC database
Verify that the user ID is a valid user in the

Active Directory. If not, use a valid user ID.
Make sure that principals for all the client users
of the web application are created in the KDC.
Invalid user ID password is used by the

client in the Basic Authentication string
when submitting requests to DataPower.
Debug the level message seen in the

mpgw (kerbDemo2MPG): request
kerbDemo2MPGPolicy_rule_0 #1 aaa:
'INPUT kerbDemo2AAAPolicy stored
in OUTPUT' failed: Rejected by
policy.
Use the correct password for the given user ID.
Syntax error in the custom XSLT stylesheet. Debug the level message seen in the
dp:transform(): local:///
kerbDemo2Custom.xsl: illegal
character ' ' at line 13 of
local:///kerbDemo2Custom.xsl

Review the XSL file that was uploaded to

DataPower and correct the code line or lines
specified in the error message.
Page 27 of 31
developerWorks
Conclusion
This article demonstrated how to set up a Multi-Protocol Gateway configuration and how to
generate Kerberos tokens in a more programmatic fashion by using the DataPower custom
stylesheet dp:get-kerberos-apreq method. In other words, you learned how to authenticate by
using a client user ID and password, and then submitted requests to the backend server using the
dynamically generated Kerberos principal name.
Though the dynamic approach required more upfront configuration and programming, the
advantage of this custom stylesheet approach was that a Kerberos keytab file no longer needed
to be imported into the DataPower MPGW configuration. Since access to the secret key was
achieved dynamically by the extracting it from the incoming client request, it did not have to be
extracted from a pre-imported, static keytab file, which helped to simplify the Kerberos keytab
administration.
Since the client user ID was propagated in the Kerberos ticket, the snoop application generated
information that identified the name of the actual end client. This was the main difference from
the first article, where the principal name displayed in the snoop output was always the name
associated with the client keytab file.
You also learned how to generate the necessary Kerberos artifacts, where those artifacts are used
and their purpose. Finally, you looked at a convenient way to test your MPGW configuration using
the "curl" utility and reviewed how to troubleshoot your configuration.

Page 28 of 31
developerWorks
Downloads
Description
Name
Size
Code sample
dbKerbDemo2Domain.zip
510KB
Code sample
kerbDemo2Custom.zip
1KB

Page 29 of 31
developerWorks
Resources
If you need further assistance, collect the following MustGather information and contact IBM
Support:
From DataPower: Collecting WebSphere DataPower SOA Appliance Security and AAA
Information
If the backend server is WebSphere: Problems with Spnego
Rewriting SOAPAction headers with WebSphere DataPower SOA Appliances
Configuring a WebSphere DataPower Kerberos-secured backend server, Part 1: Using the
DataPower Web Graphical User Interface
WebSphere DataPower SOA Appliances V4.0.2 Information Center: set-http-request-header
Using DataPower XSLT extension to add custom headers
developerWorks WebSphere DataPower zone
developerWorks WebSphere DataPower discussion forum

Page 30 of 31
developerWorks
About the authors

Bill Barrus
Bill Barrus is a Senior Software Engineer in IBM Software Group. He began his IBM
career performing mechanical design trade-off studies for the U.S. Navy F-14 avionics
upgrade program. He contributed to emerging business opportunity challenges
in support of CATIA Engineering Analysis, Lotus Workplace Client Technology,
and WebSphere Voice Server. He was the World Wide team lead of WebSphere
DataPower support to IBM Business Partners and moved to lead IBM SWG L2
support's DataPower Security team, and is now technical support team lead for the
innovative, new cloud computing offering - IBM PureApplication System.
Michael McMahon
Michael McMahon is an Advisory Software Engineer for IBM working in Research
Triangle Park, NC. He has worked on a variety of development teams and projects in
the past and currently works in the IBM DataPower and IBM PureApplication System
support organization.
Krithika Prakash
Krithika Prakash is an Advisory Engineer in the IBM DataPower Engineering team.
She specializes in software development in the areas of networking, security, and
Web services security. She has filed patents and written several articles for IBM
developerWorks in the areas of security.
Copyright IBM Corporation 2013
(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Page 31 of 31

Config Ws DP Kerberos Gui2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Config Ws DP Kerberos Gui2

Hochgeladen von

Copyright:

Verfügbare Formate

Configuring a WebSphere DataPower Kerberossecured backend server, Part 2: Using a DataPower

custom stylesheet for client user ID authentication

Michael McMahon (mmcmaho@us.ibm.com)

Scenario from the previous article

Dynamic solution scenario

Kerberos interaction in this dynamic scenario

Figure 1. Overview of the dynamic solution scenario

A disadvantage to this approach is that it requires a more complicated, programmatic

Kerberos and domain controller tasks

Create Active Directory client accounts

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 2. New AD user

Figure 3. New AD user options

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 4. ldifde command execution

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 5. demoClient1 AD attributes

Kerberos keytab file server application

Configuring a WebSphere DataPower Kerberos-secured backend

DataPower related tasks

Create the Multi-Protocol Gateway

Define the front side handler settings

Figure 6. Selecting the Front Side Protocol Handler type

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 7. Front Side Handler settings

Define the back side settings

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 8. Back side and front side settings

Define the Multi-Protocol Gateway policy

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 9. Initial MPGW Policy panel

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 10. Configure the matching rule name

Figure 11. Create a matching rule

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 12. Configure matching action

Define an AAA action

Figure 13. Drag AAA onto the rule line

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 14. Input and output settings

Figure 15. AAA Policy Add button

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 16. AAA Policy Add button

Figure 17. Bind to specified LDAP server selection

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 18. LDAP server settings

Figure 19. Define how to extract the resources

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 20. Define how to authorize a request

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 21. Run Custom Post Processing Stylesheet section

Figure 22. Upload XSL file dialog

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 23. Applying and closing the MPGW Style Policy

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 24. Applying and closing the MPGW Style Policy

Configuring the Kerberos KDC server object on DataPower

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 25. Kerberos KDC Server under the crypto configuration

Configuring a WebSphere DataPower Kerberos-secured backend

Figure 26. Configure the Kerberos KDC Server

Testing the dynamic scenario

Configuring a WebSphere DataPower Kerberos-secured backend