Protect traffic using IBM WebSphere DataPower as a security gateway

Protect traffic using IBM WebSphere DataPower as a security gateway

We can use IBM WebSphere DataPower in the Data Management Zone (DMZ) of the enterprise to protect MobileFirst mobile application traffic.

Ensure that MobileFirst Studio is installed.

Establish the stand-alone server environment on Liberty or WAS.

Protecting mobile application traffic that comes into your network from customer and employee devices involves preventing data from being altered, authenticating users, and allowing only authorized users to access applications. To protect mobile application traffic that is initiated by a client MobileFirst application, we can use the security gateway features of IBM WebSphere DataPower.
Enterprise topologies are designed to include different zones of protection so that specific processes can be secured and optimized. We can use IBM WebSphere DataPower in different ways in the DMZ and in other zones within the network to protect enterprise resources. When we start to build out MobileFirst applications to be delivered to the devices of the customers and employees, we can apply these methods to mobile traffic.
We can use IBM WebSphere DataPower as a front-end reverse proxy and security gateway. DataPower uses a multiprotocol gateway (MPGW) service to proxy and secure access to MobileFirst mobile applications. Two authentication options are demonstrated: HTTP basic authentication and HTML forms-based login between the mobile client and DataPower.
Consider adopting the following phased approach to establishing IBM WebSphere DataPower as a security gateway:

Install and configure a MobileFirst environment and test the installation with a simple application without DataPower acting as the reverse proxy.

Test that the application logic works.

Configure an MPGW on DataPower to proxy the mobile application or the operations console. Select one of the following authentication options:

Use basic authentication for end-user authentication with AAA and generate a single sign-on (SSO) LTPA token for MobileFirst Server running on WebSphere Application Server if the user successfully authenticates.

Use HTML form-based login with AAA and generate a single sign-on (SSO) LTPA token for MobileFirst Server, running onWebSphere Application Server if the user successfully authenticates.

Test the reverse proxy:

Update the MobileFirst configuration on the server with the reverse proxy configuration (see Step 1).

Update the mobile security test configuration of each mobile application to use form-based authentication so the application requests the user to authenticate immediately when the application starts. Either HTTP basic authentication or HTML form-based login is supported before the application starts. For web widgets, widget resources are accessible to the browser only after a user authenticates successfully.
Set up a MobileFirst configuration.
For each app that you are configuring, modify authenticationConfig.xml.on the server to include the following security test, realm, and login module declarations:
<securityTests>
  <mobileSecurityTest name="WASTest-securityTest">
    <testDeviceId provisioningType="none"/>
    <testUser realm="WASLTPARealm"/>
  </mobileSecurityTest>
  <webSecurityTest name="WASTest-web-securityTest">
    <testUser realm="WASLTPARealm"/>
  </webSecurityTest>
</securityTests>
 
<realms>
  
  <realm name="WASLTPARealm" loginModule="WASLTPAModule">
    <className>com.worklight.core.auth.ext.WebSphereFormBasedAuthenticator</className>
    <parameter name="login-page" value="/login.html"/>
    <parameter name="error-page" value="/loginError.html"/>
  </realm>
</realms>
<loginModules>
  
  <loginModule name="WASLTPAModule">
    <className>com.worklight.core.auth.ext.WebSphereLoginModule</className>
  </loginModule>
</loginModules>
By default, authenticationConfig.xml.is usually available in this directory: <WAS_INSTALL>/profiles/<WAS_PROFILE>/installedApps/<WAS_CELL>/IBM_Worklight_Console.ear/worklight.war/WEB-INF/classes/conf.
Restart the operations console enterprise application.
Update the client mobile app.
In the client mobile app, add the following JavaScript to the HTML MobileFirst application:
function showLoginScreen() {
  $("#index").hide();
  $("#authPage").show();
}
function showMainScreen() {
  $("#authPage").hide();
  $("#index").show();
}
var myChallengeHandler = WL.Client.createChallengeHandler("WASLTPARealm");
var lastRequestURL;
myChallengeHandler.isCustomResponse = function(response) {
  //A normal login form has been returned
  var findError = response.responseText.search("DataPower/Worklight Error");
  if(findError >= 0) {
    return true;
  //A normal login form has been returned
  var findLoginForm = response.responseText.search("DataPower/Worklight Form Login");
  if(findLoginForm >= 0) {
    lastRequestURL = response.request.url;
    return true;
  //This response is a MobileFirst Server response, handle it normally
  return false;
};
myChallengeHandler.handleChallenge = function(response) {
  showLoginScreen();
};
challengeHandler1.handleFailure = function(response) {
   console.log("Error during WL authentication.");
};
myChallengeHandler.submitLoginFormCallback = function(response) {
  var isCustom = myChallengeHandler.isCustomResponse(response);
  if(isCustom) {
    myChallengeHandler.handleChallenge(response);
  else {
    //hide the login screen, you are logged in     showMainScreen();
    myChallengeHandler.submitSuccess();
};
//When the login button is pressed, submit a login form $("#loginButton").click(function() {
  var reqURL = "/j_security_check";
  alert(lastRequestURL);
  var options = {method: "POST"};
  options.parameters = {
  j_username: $("#username").val(),   j_password: $("#password").val(),   originalUrl : lastRequestURL,   login: "Login"
};
  options.headers = {};
  myChallengeHandler.submitLoginForm(reqURL, options, myChallengeHandler.submitLoginFormCallback);
});
To retrieve the LTPA key file used for authentication from MobileFirst Server, we can also use the MobileFirst API function login method as defined in the WL.Client class: WL.Client.login("WASLTPARealm");
This call triggers the myChallengeHandler.isCustomResponse method with a JSON response, where we can retrieve the LTPA key file.
if (response.responseJSON.WASLTPARealm && response.responseJSON.WASLTPARealm.isUserAuthenticated) 
var sessionKey = response.responseJSON.WASLTPARealm.attributes.LtpaToken;
For any subsequent adapter calls that need to be proxied through the reverse proxy, we can include this sessionKey as a header within the request.
Ensure that the HTML body for the MobileFirst app reflects the login information that is to be handled by DataPower.
To add the authentication test to an application or device, add a securityTest attribute to the environment tag in the project application-descriptor.xml file.
Set the value of this attribute to the name of the security test that you declared in authenticationConfig.xml.in substep 1a. . Here is an iPad example:
<ipad bundleId="com.Datapower" securityTest="WASTest-securityTest" version="1.0">
  <worklightSettings include="false"/>
  <security>
    <encryptWebResources enabled="false"/>
    <testWebResourcesChecksum enabled="false" ignoreFileExtensions="png, jpg, jpeg, gif, mp4, mp3"/>
  </security>
</ipad>
Define a multiprotocol gateway.

In the IBM DataPower WebGUI, in the search box under Control Panel, enter Multi-Protocol and click New Multi-Protocol Gateway.

On the General Configuration page, pdefine the following settings.

Field Description
Multi-Protocol Gateway Name Provide a name for the gateway.
Response Type Select Non-XML. With this value, HTTP web application traffic (including JSON, JavaScript, and CSS) passes through the appliance.
Request Type Select Non-XML. With this value, HTTP web application requests are handled by the appliance.
Front Side Protocol
Select HTTPS (SSL). For this type of interaction in which user credentials are passed between client and server, HTTPS is appropriate. Also provide the following front-side handler details:

Name

Enter a name for the configuration.

Port Number

Enter a number for the listening port. This port number must match the port number that we specify if you define an AAA policy that uses HTML form-based authentication. See Table 3.

Allowed Methods and Versions

Select GET method to enable support for HTTP Get.

SSL Proxy

Select an SSL Reverse Proxy profile to identify the SSL server.

Multi-Protocol Gateway Policy
Click +, and then create rules to define the policies listed in the following topics, depending on the type of authentication that you decide to use:

Policy worklight-basicauth for HTTP basic authentication. See Rules for HTTP basic authentication.

Policy mpgw-form for HTML form-based login authentication. See Rules for HTML form-based authentication.

Backend URL Specify the address and port of the MobileFirst Server that is hosted on WebSphere Application Server.

Create an AAA policy that supports the HTTP basic authentication or HTML form-based login policy definedd in the previous step.

In the IBM DataPower WebGUI, in the search box under Control Panel, enter AAA, and then click Add.

Depending on the type of authentication to use, define the following settings.

For HTTP basic authentication, specify the settings as listed in the following table.

Phase Description
Extract Identity In the Methods field, select HTTP Authentication Header.
Authenticate Choose the authentication method. If WAS is using LDAP, configure LDAP here.
Extract Resource Select URL Sent by Client.
Post processing Generate an LTPA token. Specify LTPA Token Expiry, LTPA Key File, and LTPA Key File Password.

For HTML form-based login, specify the settings as listed in the following table.

Phase Description
Extract Identity In the Methods field, select HTML Forms-based Authentication. Select or create an HTML forms-based policy that has the Use SSL for Login option enabled, assigns SSL Port to the port number on which the MPGW is listening (specified in step 3), and has the Enable Session Migration option disabled.
Authenticate Choose the authentication method. If WAS is using LDAP, configure LDAP here.
Extract Resource Select URL Sent by Client.
Post processing Generate an LTPA token. Specify LTPA Token Expiry, LTPA Key File, and LTPA Key File Password.

On the Advanced page, specify the advanced settings as listed in the following table.

Field Value
Persistent Connections On.
Allow Cache-Control Header Off
Loop Detection Off
Follow Redirects Off. This value prevents the DataPower back-end user agent from resolving redirects from the back end. Web applications typically require a client browser to resolve redirects so they can maintain the context for "directory" along with setting an LTPA cookie on the client.
Allow Chunked Uploads Off
MIME Back Header Processing Off
MIME Front Header Processing Off
Results
Your MobileFirst mobile application traffic is now protected by an IBM WebSphere DataPower secure gateway. Authentication is enforced on the DataPower device and the credentials (header or LTPA token) are forwarded downstream to MobileFirst Server to establish the user identity as part of the mobile traffic.

Rules for HTTP basic authentication
Add rules to define an HTTP basic authentication policy named worklight-basicauth.

Rules for HTML form-based authentication
Add rules to define an HTML form-based authentication policy named mpgw-form.

Sample form login stylesheet
We can use this sample stylesheet to generate the HTML form login page or error page when creating rules to define an HTML forms-based authentication policy.

Sample redirect stylesheet
We can use this sample stylesheet to handle redirection and content-type rewriting. You refer to the stylesheet when you create rules to define an HTTP basic authentication policy or an HTML forms-based authentication policy.

Parent topic: Configure MobileFirst Server

Field	Description
Multi-Protocol Gateway Name	Provide a name for the gateway.
Response Type	Select Non-XML. With this value, HTTP web application traffic (including JSON, JavaScript, and CSS) passes through the appliance.
Request Type	Select Non-XML. With this value, HTTP web application requests are handled by the appliance.
Front Side Protocol	Select HTTPS (SSL). For this type of interaction in which user credentials are passed between client and server, HTTPS is appropriate. Also provide the following front-side handler details: Name Enter a name for the configuration. Port Number Enter a number for the listening port. This port number must match the port number that we specify if you define an AAA policy that uses HTML form-based authentication. See Table 3. Allowed Methods and Versions Select GET method to enable support for HTTP Get. SSL Proxy Select an SSL Reverse Proxy profile to identify the SSL server.
Multi-Protocol Gateway Policy	Click +, and then create rules to define the policies listed in the following topics, depending on the type of authentication that you decide to use: Policy worklight-basicauth for HTTP basic authentication. See Rules for HTTP basic authentication. Policy mpgw-form for HTML form-based login authentication. See Rules for HTML form-based authentication.
Backend URL	Specify the address and port of the MobileFirst Server that is hosted on WebSphere Application Server.

Phase	Description
Extract Identity	In the Methods field, select HTTP Authentication Header.
Authenticate	Choose the authentication method. If WAS is using LDAP, configure LDAP here.
Extract Resource	Select URL Sent by Client.
Post processing	Generate an LTPA token. Specify LTPA Token Expiry, LTPA Key File, and LTPA Key File Password.

Phase	Description
Extract Identity	In the Methods field, select HTML Forms-based Authentication. Select or create an HTML forms-based policy that has the Use SSL for Login option enabled, assigns SSL Port to the port number on which the MPGW is listening (specified in step 3), and has the Enable Session Migration option disabled.
Authenticate	Choose the authentication method. If WAS is using LDAP, configure LDAP here.
Extract Resource	Select URL Sent by Client.
Post processing	Generate an LTPA token. Specify LTPA Token Expiry, LTPA Key File, and LTPA Key File Password.

Field	Value
Persistent Connections	On.
Allow Cache-Control Header	Off
Loop Detection	Off
Follow Redirects	Off. This value prevents the DataPower back-end user agent from resolving redirects from the back end. Web applications typically require a client browser to resolve redirects so they can maintain the context for "directory" along with setting an LTPA cookie on the client.
Allow Chunked Uploads	Off
MIME Back Header Processing	Off
MIME Front Header Processing	Off