Secure mobile access to enterprise applications through IBM WebSphere DataPower SOA Appliances

Extending security to Worklight applications and the broadest range of mobile device APIs


The introduction of mobile device access to enterprise applications has meant that a flexible IT security approach is more important than ever. In the past, companies could assume that a web browser in a corporate office was being used to access their systems. With the increasing use of BYOD (bring your own device) mobile access, security capabilities are more varied at a time when security concerns are highest. Because of the inherent complexity of security components, ease-of-use is a primary concern. Furthermore, it’s important to integrate any solution with your company’s existing investments in web and security infrastructure. It’s equally important that the new components provide flexibility for future topologies, as things inevitably evolve. Finally, the solution should be as complete as possible, to avoid a piecemeal approach.

What this all means is that the security approach must be extremely flexible, effective, easy to maintain, re-usable, complementary to existing patterns, and provide as complete an approach as possible.

This article describes:

  • How IBM WebSphere DataPower Integration Appliance XI52 can extend your security infrastructure, while taking advantage of existing investments.
  • How the DataPower appliance can work in conjunction with both existing and new infrastructure (including IBM Worklight® V5) to enable the broadest rollout of mobile device APIs, including varied security token support.
  • How to quickly set up a “mobile DMZ” using a common technique for browser detection to implement an integrated single sign-on (SSO) environment with a DataPower multi-protocol gateway and web application firewall.

The sample solution

The specific versions of servers and software used in the example presented here include IBM WebSphere DataPower Integration Appliance XI52 V5, integrating with IBM Worklight V5.0.5 deployed on IBM WebSphere Application Server V7. The LTPA token provides security for SSO. The sample environment used both supplied DataPower functions and some custom XSLT scripts. Worklight Studio V5.0.5 installed with IBM Rational® Software Architect V8.5.1 is used for construction of the simulated mobile device and XSLT editing. The final result will detect a mobile browser in the HTTP header, redirect the result to a web application firewall service on the DataPower machine, then forward the LTPA token along with the request to a test Worklight server configured as part of a WebSphere Application Server security domain.

The overview is presented at an architecture level and does not depend on specific technology skills. To implement the example, you’ll need access to a DataPower device, Worklight Studio V5.0.5, and a WebSphere Application Server configured with Worklight. You can try out the concepts using an Eclipse based-tool like IBM Rational Application Developer. To make any modifications, you will need a basic understanding of XML and XSLT.

New mobile challenges to the enterprise

The traditional enterprise is changing. In the past, access to critical, in-house applications could be standardized and secured according to location (such as the corporate office) and device (such as a particular browser vendor). Today, a growing, flexible workforce is integrating work activities with personal ones, and using mobile devices to do it. To support this need, companies are adapting by exposing critical, in-house applications to externally available sites and devices.

Any mobile enablement needs to be supported by a strong and comprehensive policy and strategy. The enterprise needs to consider what BYOD devices will be supported and what employee roles will be eligible to use them. It needs to consider how mobile support will complement existing services. Moreover, it should consider how such support affects how in-house applications are developed in the future. All web-based applications should be developed adhering to mobile-friendly standards and platforms such as HTML5, Dojo, and JSON-capable interfaces.

Ideally, enterprises will not want to lose value in the existing IT enablement initiatives. Fortunately, with the light footprint provided by DataPower appliances and Worklight, support for mobile devices can be introduced while still using many existing assets and infrastructure. Because security is paramount, DataPower should be deployed in a DMZ. Doing this ensures that connectivity from that DMZ to back end components use appropriate firewalls, proxies, or virtual private networks (VPNs).

Security framework considerations

This article does not cover all of the many architectural considerations that a company's mobile solution should consider. You'll need to work with your IT team and business process owners for the strategy that best fits your needs. When doing so, review your company's policies and requirements for the various mobile user types: customers, business partners, and employees who desire to work using a mobile device. Here are a few areas for you to consider within your company's overall mobile architecture strategy:

  1. Solution governance covers the policies your company will apply and enforce, for example:
    • Device usage: Restricting sharing of the device used to access the application.
    • Data policy: Determining if the data displayed is classified as suitable for display in a potentially public arena.
    • Updates: How patches and other software updates will be rolled out and enforced.
    • User registration and identity management: How employees, business partners, and customers will register for access and perform administration tasks, such as resetting passwords.
  2. Security-specific considerations include:
    • Encryption: Consider things other than SSL support for the transport. Give thought to whether to secure things not directly associated with call transport such as mobile device memory, including data cards (for example, SD card).
    • Software security: What to use for malware and virus detection, and whether you care about “jail broken” devices.
    • Firewalls and VPNs (virtual private networks): How to limit network exposure and accessibility with the appropriate use of firewalls, VPN tunnels, and proxies.
    • Physical security: What happens when a device is stolen?

IBM mobile solutions

IBM has addressed the needs of mobile with the addition of the IBM Mobile Foundation, which includes IBM WebSphere Cast Iron® for hybrid cloud integration, IBM Endpoint Manager for policy, data, and endpoint security, and IBM Worklight for multi-platform device support. These components enable you to quickly extend your capabilities to cover mobile devices regardless of the type of device used. One particular feature to note is that Worklight Server can be installed on top of WebSphere Application Server, which extends the security and power of WebSphere Application Server to include mobile device support.

Mobile plus DataPower

The remainder of this article focuses on quickly extending the capabilities of the IBM web hosting infrastructure, including the IBM Mobile Foundation, to include a DataPower appliance used as a gateway to the mobile world.

The reasons for using a DataPower appliance as a DMZ machine are many:

  • As a hardened, purpose-built appliance, it is resistant to hacking. DataPower’s firewall capabilities help protect back end servers from direct access from clients outside the organization, including protection from things like SQL injection, computer viruses, and cross-site scripting.
  • DataPower also supports multiple security tokens and SSL (more on this later), while providing support for forms and other user validation pages on the DataPower device itself. It integrates with the LDAP server as part of its authentication, authorization and accounting (AAA) feature.
  • Furthermore, even with this extensive support, you can extend token support to use DataPower as a security token service client to an intelligent identity manager (such as IBM Tivoli® Federated Identity Manager) to generate and translate custom tokens for you.

That’s a lot of security capabilities loaded into a single device, and it integrates extremely well with existing security infrastructure.

Starting point reference architecture

The reference infrastructure shown in Figure 1 is the starting point for this discussion. Your configuration may differ in the details, but the approach shown here is a common one. Before introducing the new pieces, let’s look at how the old approach works.

Figure 1. Reference enterprise-level web architecture
Figure 1.  Reference enterprise-level web architecture
Figure 1. Reference enterprise-level web architecture

Here is a quick overview of the key pieces:

  • Load balancer: A load balancer (such as IBM WebSphere Edge Server) or a hardware appliance (often called an IP sprayer) is used to balance traffic among the clusters. DataPower appliances, with the application optimization (AO) function, also have the capability of self-balancing among the appliances and performing intelligent load-balancing to the back end application server.
  • Reverse proxy or web server: This includes things such as IBM Security Access Manager WebSEAL, IBM HTTP Server, or Apache, or an existing DataPower instance. This is used as the “first touch” enforcement policy for security. It is used as the runtime enforce enterprise policy, such as the “three strikes” rules (three failed authentication attempts and you are locked out for a time), as well as provides a firewall between public Internet and private intranet.
  • Policy server: An example is IBM Security Access Manager, which provides enterprise-wide policy management points and integrates with the reverse proxy.
  • Application server: WebSphere Application Server houses the critical applications. Its global security features make for easy access and federation to multiple security stores, including LDAP (Lightweight Directory Access Protocol) servers and token generation. It’s also the base installation for both the security token service and the Worklight servers.
  • Security token: As users are authenticated to the systems they want to access, the authorization to access them is held by security tokens. Examples of security token types include IBM’s Lightweight Third Party Authentication (LTPA) token and Security Access Markup Language (SAML). Security tokens are passed among the software components of the infrastructure to carry the authentication information to enable access to the systems.
  • Security token service: A good example is IBM Tivoli Federated Identity Manager (TFIM). Among its capabilities, it provides security token translation capability (for example, between LTPA and SAML).
  • Security registry: In large enterprises, this is usually done through LDAP. A good example is IBM Tivoli Directory Service, which manages the security schemas for your users.

Mobile DMZ implementation

Follow the magnifying glass in Figure 2 to see how to extend the existing DMZ to be a mobile DMZ as well. DataPower’s XML firerwall capability will be used to separate internal traffic from external traffic, and you will use Worklight to handle the device specific APIs from your mobile device.

Figure 2. Reference architecture with mobile DMZ
Figure 2. Reference architecture with mobile DMZ
Figure 2. Reference architecture with mobile DMZ
Figure 3. Mobile DMZ detail
Figure 3.  Mobile DMZ detail
Figure 3. Mobile DMZ detail

Isolating the DMZ in Figure 3 shows the sample mobile DMZ will contain a DataPower machine in three roles:

  • Multi-protocol gateway for routing
  • Reverse proxy, using its authentication, authorization and audit capabilities
  • A guard against threats, such as computer viruses, SQL injection, URL scanning, and so on.

Figure 3 shows that the non-mobile traffic can also be directed to a cluster of reverse proxy servers, but that’s not required. DataPower has the inherent capacity and high availability to converge all traffic, directing the appropriate class of traffic to the proper servers.

These roles assigned to DataPower can be performed on the same machine:

  • First, it’s used as a reverse proxy – the same role that ISAM WebSEAL has in the reference architecture. A user must authenticate to the DataPower device before being passed to any back end server.
  • Second, it’s the routing server for request. It looks at the HTTP header and forwards the request accordingly.

For threat protection, you will use DataPower’s web application firewall, because it contains a lot of threat protection capabilities and it’s very easy to configure.

One of the key elements is that DataPower can generate the SSO domain cookie that enables requests to flow around the infrastructure. This is a key part to ensuring security integration The reasons for doing this are two-fold:

  • It is used as the DMZ machine of choice for firewall control.
  • It is used as a security server. It’s also a secure high availability device, so it’s a natural fit in this DMZ role.

Proof of concept environment

The key to this example is how the DataPower appliance can authorize users, route mobile traffic separately from non-mobile traffic, and generate an LTPA security token that enables SSO. In this case, we’ll specifically show that along with routing the request, the LTPA token generated from DataPower can be accepted by the Worklight-enabled application server to provide access to the secured mobile application.

To show this, we’ve put together as small of a footprint as possible while still showing non-trivial interaction. This proof of concept example does not cover all of the sophisticated security capabilities offered as part of Worklight; it only shows the highest level token-friendly application as part of a mobile browser. There are other pieces that you should strongly consider for a production environment; for example, DataPower cleanly integrates with Tivoli Federated Identity Manager, which is an excellent tool for producing and consuming security tokens. Still, this example does cover the highest level security and demonstrates the concepts.

To build this proof of concept, you will need:

  • Web browser

    A web browser with HTTP agent modifying plugins is used here to simulate mobile traffic. The DataPower scripting detects the mobile device by identifying the user agent stream sent by the plugin. Suggestions for the web browser plugins include:

    • User Agent Switcher for Firefox
    • Cookie+ manager for Firefox
    • A browser on a mobile phone connected through a wireless connection to your company’s wireless router (as shown in the figures in this article).
  • Worklight installed on WebSphere Application Server

    See Related topics to perform this setup. As you would expect, Worklight can leverage the high-powered security capabilities of WebSphere Application Server. A common LTPA token store will be shared between DataPower , the WebSphere Application Server administrative console, and the secured mobile application. For this application, we used:

    • Worklight Studio V5.0.5
    • Embedded WebSphere Application Server V7.0.0.15.
    The console was modified to use a new security role for a “Type 1” security setting. See Related topics to perform this setup.
  • A central security server

    You need this for the domain-wide server to see SSO. The examples shown here used IBM Tivoli Directory Server V6.1.

  • Worklight Studio V5.0.5

    You’ll need Worklight Studio to create a sample Worklight application. IBM Worklight Developer Edition 5.0 is available to download and use at no cost.

  • Sample mobile application

    Download the sample Worklight application included with this article to use for this exercise.

  • A DataPower device

    The DataPower device used for this demo is the XI52 integration appliance, firmware version is The sample application consist of two types of multi-protocol gateways. Figures 5 and 6 show the flows used by the script in the DataPower device. Compare them to Figure 9, which shows the actual processing rules used by this solution.

Figure 4 shows the proof of concept environment.

Figure 4. Proof of concept environment
Figure 4. Proof of concept environment
Figure 4. Proof of concept environment

Figure 5 shows the LTPA token consuming logic.

Figure 5. Flowchart of the proof of concept token consuming script
Figure 5.  Flowchart of the proof of concept token consuming script
Figure 5. Flowchart of the proof of concept token consuming script

The first part of the multi-protocol gateway will invoke the AAA rules to secure the server and consume the LTPA tokens for SSO. It first detects a match for the LTPA cookie using a match rule for HttpTag :cookie with value *LtpaToken2*. It then detects the HTTP header and forwards the request to the appropriate server, either the Worklight-enabled web application firewall or the “regular” web application firewall.

Figure 6 shows flow for the LTPA producing script.

Figure 6. LTPA producing script flow
Figure 6. LTPA producing script flow
Figure 6. LTPA producing script flow

If the LTPA cookie is not present, the nested script logic will fall through to the LTPA producing scripts. These use a match rule for the web application firewall landing page. The key here is to generate an LTPA token that is valid for the entire domain.

Domain-wide tokens for SSO

A key element here is how these servers are able to securely accept traffic from each other. Of course, securing the communications channel with Secure Sockets Layer (SSL) encryption is an essential part to securing an application, and all of the servers support SSL at each endpoint. But what’s really needed is a security token that’s understood among all of the servers so that an SSO domain is created. For that, you will use IBM LTPA token stored as a cookie on the user’s browser.

The present release of DataPower is designed to be as secure and narrowly restrictive as possible, so it generates a “host”-level cookie from its LTPA scripts. It can receive and process a “domain”-level cookie generated from WebSphere Application Server, but you want any user that authenticates to DataPower be able to access WebSphere Application Server and Worklight resources without being challenged again. For that, an XSLT script is provided in Listing 2 to generate a domain-wide LTPA cookie.

Some key elements are required to make this work:

  • Common security server: A user must, of course, be valid in all domains, and the easiest way to achieve this is to have a common LDAP Server.
  • Common realms: LTPA tokens have realms. Use the same realm name everywhere. We use tonycustom in this example.
  • Common LPTA key file: Use the one exported from WebSphere Application Server.

Splitting traffic between mobile and other web applications

One key to the solution is how to detect the mobile traffic. There are a couple of ways to split out mobile HTTP requests from other traffic. One common way is to detect the User-agent field in the HTTP header for the presence of a mobile browser. We’ll do that in a multi-protocol gateway, and challenge the user with a simple, basic authentication rule that prevents unsecured access to the server. Here, we’ll show it works on an iPhone Safari browser directed to our Worklight application. For comparison, requests from a desktop browser, such as Internet Explorer, are sent to our “regular” applilcation server’s “snoop” servlet. (These URLs are similar but are, in fact, completely different locations. You can change the URL values to any two sites you wish for your own testing.)

Creating the mobile DMZ

There are two main parts to creating the mobile DMZ: creating the custom map credentials script (Listing 2) and the SSO setCookie script (LIsting 2). (Assume that authentication has already passed; you are just mapping the credential tree so that the setCookie script can use it.)

Listing 1 shows the logic to select the username and password from the DataPower context, and include them in the DataPower LDAP Search function. If found, the user is allowed to exit the script.

Listing 1. Script to map credentials for LTPA token: domain-wide-MC.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl=""
    extension-element-prefixes="dp regexp"
    exclude-result-prefixes="dp" version="1.0">
	<xsl:strip-space elements="serverAddress portNumber bindDN bindPassword filter" />
	<xsl:template match="/">
		<xsl:variable name="username"
			select="dp:variable('var://context/WSM/identity/username')" />
		<xsl:variable name="password"
			select="dp:variable('var://context/WSM/identity/password')" />
		<xsl:variable name="targetDN"
		<xsl:if test="string-length($username)=0">
			<dp:reject>No input yet</dp:reject>
		<xsl:variable name="resp"
			select="dp:ldap-search($serverAddress, $portNumber, $bindDN, 
$bindPassword, $targetDN,$attributeName, $filter, $scope, $sslProxyProfile, 
$ldapLBGroup)" />

		<!-- The format of the resp should be something like: 
			<LDAP-search-results xmlns="">
			<result> <DN>cn=Joe User, cn=Users,dc=example, 
			dc==com</DN> </result> </LDAP-search-results> -->

		<xsl:variable name="userDN"
*[local-name()='result']/*[local-name()='DN']" />

		<xsl:if test="string-length($userDN)=0">
			<dp:reject> USER NOT PRESENT IN LDAP"</dp:reject>
		<!--  outer if -->
		<!-- </xsl:if> -->
		<xsl:variable name="addlTree"
			select="',cn=Users,secAuthority=Default,o=ibm,c=us'" />
		<xsl:variable name="uniqueID" select="concat($userDN,$addlTree)" />
		<!-- Record to the log the DN results returned from the ldap-search -->
		<!-- Build a properly formatted nodeset so that the AAA action will 
			update the var://context/WSM/identity/credentials -->
		<xsl:variable name="LTPARealm" select="'tonycustom/'" />
		<xsl:message dp:priority="error">
			DEBUG  - Script ending in LDAP SUCCESS
			<xsl:value-of select="$uniqueID" />
		<entry type="Custom">
			<xsl:value-of select="$uniqueID" />

The important thing to note is this line, which calls the LDAP server in Search mode to map the credentials needed:

<xsl:variable name="resp"
select="dp:ldap-search($serverAddress, $portNumber, $bindDN, $bindPassword,
$targetDN,$attributeName, $filter, $scope, $sslProxyProfile, $ldapLBGroup)" />

Know that to find the user in the LDAP directory, the $TargetDN must include the LDAP schema attributes to locate the correct user in the LDAP tree.

Listing 2 shows the script to map the cookie.

Listing 2. Script to set the LTPA cookie: set-cookie.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" 

  <xsl:template match="/">
    <dp:remove-http-response-header name="Set-Cookie" />

    <xsl:variable name="token-var" select="dp:variable('var://context/AAA/PPLTPA')"/>
    <xsl:variable name="token" select="$token-var//LTPAAttribute[Name = 

    <dp:set-response-header name="'Set-Cookie'" value="concat('LtpaToken2=', $token, 
';; Path=/;')" />

    <xsl:copy-of select="//message/*" />


Listing 2 shows the response script to set the LTPA session cookie in the browser for user in SSO. In the set-cookie script, the important thing to note is this line:

<dp:se Table 1 Script to Map Credentials for LTPA Tokent-response-header name="'Set-Cookie'"
value="concat('LtpaToken2=', $token, ';; Path=/;')" />

Notice that the setting is made to the domain-wide “” domain.

The multi-protocol gateway will detect the browser and route to the mobile back end.

Listing 3 shows an example of the DataPower XSLT file that does the transformation.

Listing 3. XLST file for content-based routing based on browser
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl=""
	extension-element-prefixes="dp" exclude-result-prefixes="dp" version="1.0">
	<xsl:template match="/">
		<xsl:variable name="fireFoxBackSideURL" 
select="''" />
		<xsl:variable name="iPhoneBackSideURL" 
select="''" />
		<!-- We'll let Chrome route just like an iphone -->
		<xsl:variable name="chromeBackSideURL" 
select="''" />
		<xsl:variable name="nonMobileBackSideURL" 
select="''" />
		<xsl:variable name="httpHeader"
			select="dp:variable('var://service/original-content-type')" />
		<!--- -->
		<xsl:message dp:priority="error">
			Version 2: The $httpHeader value is:
			<xsl:value-of select="$httpHeader" />
		<xsl:message dp:priority="error">
			The dp:http-request-header() value is:
			<xsl:value-of select="dp:request-header('User-Agent')" />
		</xsl:message> <!--- -->
			<!-- var://service/routing-url is a write-only variable 
				documented in the Extension Elements/Functions Catalog. 
				See below for reference. -->
			<xsl:when test="(contains(dp:request-header('User-Agent'),
				<dp:set-variable name="'var://service/routing-url'"
					value="$chromeBackSideURL" />
				<dp:set-variable name="'var://local/dpvar_route'" 
value="$chromeBackSideURL" />
				<xsl:message dp:priority="error">
					Detected Chrome: Setting URL is:
					<xsl:value-of select="$chromeBackSideURL" />
			<xsl:when test="(contains(dp:request-header('User-Agent'),
				<dp:set-variable name="'var://service/routing-url'"
					value="$iPhoneBackSideURL" />
				<dp:set-variable name="'var://local/dpvar_route'" 
value="$iPhoneBackSideURL" />
				<xsl:message dp:priority="error">
					Detected iPhone: Setting URL is:
					<xsl:value-of select="$iPhoneBackSideURL" />
			<xsl:otherwise> …line                        
				<!—est of script omitted  -->

Listing 3 detects the user agent in the HTTP request header. Different browsers set this agent value differently. Based on the type of browser detected, the DataPower variable 'var://service/routing-url' is set to redirect the request to a web application firewall that acts as the secure front end to the targeted request.

An important thing to note is the line below, which tests the browser to detect the mobile device:

<xsl:when test="(contains(dp:request-header('User-Agent'),'iPhone'))">

This line uses http Request user agent to detect that an iPhone is being used This way, mobile browsers or other criteria can be used to route appropriate content to the Worklight server and the rest to another or default back end.

To show this script working without a mobile device, the iPhone logic is duplicated for the Chrome browser, so the same routing will occur using Chrome as it would otherwise do for an iPhone device.

The result is a landing page wrapped inside a DataPower web application firewall. Doing this demonstrates a couple of things:

  • Nothing leaves DataPower’s domain; it is all secured through the web application firewall.
  • Having a landing page which then redirects to the full page inside the firewall, means that JavaScript™ and other redirects to page links can be minimized.

Programming notes

The scripts and sample materials provided here are for demonstration purposes only:

  • “Basic authentication” type challenges were used, rather than form-based, even though the interaction might seem to be more intuitive on login forms. This was done to illustrate the role of the realm, which appears on the Basic Authentication challenge dialog.
  • URLs are hardcoded in this example, but DataPower variables could be used, which could be accessed from the scripting interface on the DataPower machine.
  • Also, it is very important to use the recommendation to turn “follow redirects” off. This prevents problems with images and other links embedded in the page. Figure 8 shows this setting.
  • When modifying the XSLT scripts, be sure to watch the white space when using the cleanup feature in the XML wizard to be sure excessive added whitespace is added in.
  • Finally, although SSL setup was omitted from this article, no production server should omit SSL setup on any secure channels.

Key configuration notes

Complete steps for this setup are included in the download materials. However, there are key steps you should be aware of when performing this configuration, and these are highlighted here to illustrate the relationship among the components.

  • DataPower configuration

    The initial firewall for content-based routing in the user header is done from a multi-protocol gateway definition (Figure 7).

    Figure 7. Multi-protocol gateway high level definition
    Figure 7 Multi-protocol gateway high level definition
    Figure 7 Multi-protocol gateway high level definition

    Using the best practices described in the DataPower SOA handbook, security rules are nested. The first rule Dworks_Mobile_MPGW_Policy_rule_1 detects the *LtpaToken2* string in a cookie: if present, it allows passage to the browser Route icon. If no cookie is present, control passes to the Dworks_Mobile_Policy_rule_0, which hold logic to generate the LTPA token, set the cookie (in the Transform step), and then passes to the browser Route icon.

    The next step involves an important setting, Follow Redirects, to ensure that the test resolves all of the embedded JPEGs and URLs (Figure 8).

    Figure 8. Important setting: Follow Redirects
    Figure 8. Important setting: Follow Redirects
    Figure 8. Important setting: Follow Redirects

    The Dworks_Mobile_MPGW Policy is where both the AAA policy and the browser detection and back end routing occurs. Each of the final endpoints is wrapped in a web application firewall (Figure 9).

    Figure 9. DataPower web application firewalls
    Figure 9. DataPower web application firewalls
    Figure 9. DataPower web application firewalls
  • Application server LTPA export

    Although not shown here in detail, the understanding is that the mobile browser traffic would be sent to the secured Worklight server installed on top of a WebSphere Application Server, and all other traffic would be passed to the non-Worklight application server. Per best practices, we assume the WebSphere Application Server has global and application security enabled, and that Worklight is secured within itself using the setup described in the Worklight security document.

    The key is sharing LTPA files (Figure 10).

    Figure 10. WebSphere Application Server export LTPA panel
    Figure 10. WebSphere Application Server export LTPA panel
    Figure 10. WebSphere Application Server export LTPA panel

    In addition, the name of the realm is important (Figure 11). The name used in WebSphere Application Server should match the realm name specified in the HTTP BasicAuthentication Realm in the DataPower Extract Identity tab (Figure 12).

    Figure 11. WebSphere AppServer highlight showing realm
    Figure 11 WebSphere AppServer highlight showing realm
    Figure 11 WebSphere AppServer highlight showing realm
    Figure 12. DataPower panel for Extract Identity
    Figure 12. DataPower panel for Extract Identity
    Figure 12. DataPower panel for Extract Identity
  • DataPower LTPA consuming panel

    Figure 13 shows the important panel, listing the LTPA token settings on the web application firewall. This panel is where the LTPA keys export from Figure 10 is imported to the DataPower configuration.

    Figure 13. DataPower panel for LTPA post-processing generation
    Figure 13. DataPower panel for LTPA post-processing generation
    Figure 13. DataPower panel for LTPA post-processing generation
  • Worklight secure configuration

    Figure 14 shows that this realm name is also important in the Worklight configuration, where it’s used in the authenticationConfig.xml file.

    Figure 14. Worklight Authentication Configuration Editor
    Figure 14.  Worklight Authentication Configuration Editor
    Figure 14. Worklight Authentication Configuration Editor

    And finally, the realm name is used in the Worklight WAR file. Note the realm-name in the XML shown in Listing 4 added to the web.xml file.

    Listing 4. Web.xml additions to secure the WAR file for WebSphere Security

Testing it out

The Worklight application included with this article is very simple. To test it, you’ll need one web browser, such as Firefox, loaded with the User Agent plugin to simulate a mobile device, and a second browser, such as Chrome, to simulate “regular” traffic. To test, launch this URL in Firefox: http://<datapower_appliance >:2091/, where <datapower_appliance> is the DNS name of your DataPower appliance. The 2091 is the port configured for the multi-protocol gateway service on the appliance.

You will first be challenged by the AAA policy on the web application firewall (Figure 15).

Figure 15. iPhone AAA basic authentication challenge
Figure 15. iPhone AAA basic Authentication challenge
Figure 15. iPhone AAA basic Authentication challenge

Notice the LTPA realm. This matches the realm configuration on WebSphere Application Server.

After authenticating, you will be passed to the backend URL you coded in the XSLT file, which is the Worklight enabled application server (Figure 16).

Figure 16. Safari test redirected to Worklight landing page
Figure 16.  Safari test redirected to Worklight landing page
Figure 16. Safari test redirected to Worklight landing page

When you follow the link displayed, you end up on the Worklight welcome page (Figure 17).

Figure 17. Worklight custom, secure application welcome page
Figure 17. Worklight custom, secure application welcome page
Figure 17. Worklight custom, secure application welcome page

When directing to the firewall, you can also get to the Worklight console, since you have authenticated and have an LTPA token (Figure 18).

Figure 18. Secured Worklight console accessed via DataPower web application firewall
Figure 18. Secured Worklight console accessed via DataPower web application         firewall
Figure 18. Secured Worklight console accessed via DataPower web application firewall

It also goes backwards. If you were first challenged by accessing the application server URL at http://<appserver>:9060/ibm/console, then the LTPA token generated by the application server would be accepted by the DataPower web application firewall.

If you’re testing on your workstation, you can use the cookie detector (Cookie+ manager, in this case) to see the LTPA token (Figure 19).

Figure 19. Cookie+ manager to see LTPA token cookie
Figure 19. Cookie+ manager to see LTPA token cookie
Figure 19. Cookie+ manager to see LTPA token cookie


This article showed how an IBM WebSphere DataPower Appliance can act as a DMZ between the world of mobile devices and your existing infrastructure. Using a simple technique of browser detection, DataPower can route browser requests to the Worklight server for a full suite of native API support. This can be an extensible way to quickly build infrastructure to support mobile while providing a good return on initial investment.


The authors recognize and thank the many IBM colleagues, consultants, architects, and development teams who developed these innovative solutions and took their time to document and share their experiences and lessons learned. The authors extend special thanks to John Rasmussen and Shiu-Fun Poon, who provided the base for the SSO routing scripts listed in this paper.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=WebSphere, Mobile development
ArticleTitle=Secure mobile access to enterprise applications through IBM WebSphere DataPower SOA Appliances