IBM Worklight server configuration for FIPS 140-2 validation and certification, Part 2: Deploying your mobile app on WebSphere Application Server

In this article, the second in a two-part series, learn how to set up, configure, and validate a distributed IBM® WebSphere® Application Server network; deploy and validate IBM MobileFirst solutions; configure end-to-end SSL communications; configure IBM Worklight Server for Federal Information Processing Standard (FIPS) 140-2 (Cryptographic Module Validation Program) compliance; and verify and validate the end-to-end working of the mobile application for its intended purpose: FIPS 140-2 compliance for server-side validation and certification.

Share:

Bhargav Perepa (bvperepa@us.ibm.com), WebSphere Architect and IT Specialist, IBM

Bhargav PerepaBhargav Perepa is a WebSphere architect and IT specialist in the IBM Federal Software Group in Washington DC area. Previously, he was a developer in the Austin WebSphere Development Lab and had Smalltalk and C++ development experience at IBM Chicago. Bhargav holds a master's degree in Computer Science from the Illinois Institute of Technology, Chicago, and a master's in business administration (MBA) from the University of Texas, Austin.



12 June 2013

Also available in Portuguese

Introduction

About this series

This two-part series explains how to configure IBM Worklight Server for FIPS 140-2 compliance testing. Federal government agencies often require that vendor products to be used for solution building and deployment comply with this computer security standard.

In Part 1 of this series on configuring IBM Worklight Server for Federal Information Processing Standard (FIPS) 140-2 compliance testing, you learned how to set up IBM MobileFirst products on IBM WebSphere® Application Server Liberty and Base Profiles, working with IBM DB2® as the back-end database. You learned how to install, configure, develop, and test using IBM Worklight Studio, Worklight Server, and the IBM Worklight Application Center, working with Oracle software development kit (SDK) and the IBM Java™ SDK, Google Android SDK, Android Emulator, and IBM mobile browser simulator capabilities. In addition, you learned how to develop a simple mobile application using Worklight Studio to test compliance validation and certification of the infrastructure for FIPS 140-2 compliance, with infrastructure logging, tracing, and instrumentation.

In this article, you learn how to install Worklight Server deployed to a WebSphere Application Server Network Deployment Profile (also called a distributed topology configuration); how to enable server-side, end-to-end security; how to configure the server-side infrastructure for FIPS 140-2 compliance; and finally how to instrument, collect, analyze, and validate FIPS 140-2 compliance from logging, tracing, and instrumentation facilities in the WebSphere infrastructure.

Get IBM Worklight

Worklight is a comprehensive platform for creating and deploying native, HTML5, and hybrid mobile apps. The Worklight framework facilitates agile development as well as testing and delivery of mobile applications with increased code reuse across Android, iOS, Blackberry, and Windows Metro platforms. In addition, it lowers development costs by leveraging widely available web technologies and standards.

Download the free IBM Worklight Developer Edition.

WebSphere Application Server Network Deployment Profile v8.5.0.1, at its core, is a distributed application server configuration platform that features central administration and management, workload balancing, and clustering/failover capabilities on to which Java language business applications can be deployed. In a Network Deployment Profile configuration, a cell constitutes a single administrative domain that can contain a group of nodes, with each node potentially containing multiple application server instances along with a single instance of a node agent per node.

You manage and administer the nodes by communicating with the node agents from a single point. A centralized and consolidated master repository that you manage contains all the configuration and application files for each node in the cell. All the nodes maintain their node-specific state information in their local copies. You propagate and synchronize the master repository state changes to local copies of nodes regularly.

Version applicability

The steps in this article are applicable to the latest versions (Worklight v5.0.6.1 and WebSphere v8.5.0.2), even though figures may refer to previous versions. All steps have been validated for Worklight v5.0.6.1 and WebSphere v8.5.0.2.

In a typical setup, it is common to have an IBM HTTP Server (or other supported web server) along with a WebSphere Application Server plug-in in the Network Deployment Profile configuration. In this topology, the web server serves requests for static content, forwards requests for dynamic content (JavaServer Pages technology, servlets, portlets, and so on) to WebSphere Application Server automatically using a plug-in, provides load balancing and failover capabilities for applications hosted on a static application server cluster, provides caching capabilities, and functions as a Secure Sockets Layer (SSL) connection termination from client communication.

Figure 1 shows a Network Deployment Profile architecture with deployed IBM MobileFirst applications.

Figure 1. Proposed use case Network Deployment Profile architecture with deployed applications
Image showing the proposed use case Network Deployment Profile architecture with deployed applications

Figure 2 shows the implemented use case Network Deployment Profile architecture with deployed IBM MobileFirst applications.

Figure 2. Implemented use case Network Deployment Profile architecture with deployed applications
Image showing the implemented use case Network Deployment Profile architecture with deployed applications

Figure 3 shows a more generic operational Network Deployment Profile architecture pattern. The implementation shown in Figure 2 is a special case of the deployment topology in Figure 3 with all components running on single node instance. By distributing runtime components to multiple, separate nodes, you make your topology architecture operationally ready.

Figure 3. Typical Network Deployment Profile architecture pattern
Image showing a typical Network Deployment Profile architecture pattern

Set up a distributed, clustered Network Deployment Profile

To set up a distributed, clustered Network Deployment Profile, complete the following steps:

  1. Provide the required authority to the DB2ADMIN ID for the APPCNT, WLREPORT, and WRKLGHT databases:
    1. Select the running instance of DB2COPY1 by clicking the DB2 icon, then click DB2 Control Center > All Databases > WRKLGHT > Selected > Authorities > User > DB2ADMIN > Grant All. Click OK.
    2. Repeat the above step for the WLREPORT and APPCNTR databases.

    The distributed topology design features one Deployment Manager profile and two application server profiles, with their respective node agents existing on one physical server. IBM HTTP Server with the plug-in also reside on the same server.

  2. Install WebSphere Application Server Network Deployment Profile v8.5.0.0:
    1. Launch Installation Manager.
    2. Configure the local repository containing installation binaries.
    3. Install the required components.
  3. Update WebSphere Application Server Network Deployment Profile v8.5.0.1:
    1. Launch Installation Manager.
    2. Select the Update option.
    3. Sign in with the registered IBM ID and password, and follow the update instructions.
  4. Create the Deployment Manager by running the command script provided.
  5. Create WebSphere Application Server profiles in the defined WebSphere Application Server nodes with their respective node agents by running the command script provided (see the Download section later in this article).
  6. Create and start the WebSphere Application Server cluster named MobileCluster.

    Figure 4 shows the successfully configured WebSphere Application Server cluster MobileCluster.

    Figure 4. WebSphere Application Server cluster MobileCluster
    Image showing the WebSphere Application Server cluster MobileCluster
  7. Create an instance of IBM HTTP Server, HTTP Administration Server, and HTTP Server plug-in components.
  8. Configure the plug-in by running the generated script.
  9. Propagate the plug-in to the cell-wide topology by completing the regeneration and propagation steps.
  10. Create a cluster-scoped DB2 XA-compliant Java Database Connectivity (JDBC) provider.
  11. Create Java Authentication and Authorization Service-J2C authentication data for the DB2 provider.
  12. Create a DB2 data source called WASV7DB.
  13. Create the WASV7DB database with an increment table in DB2.
  14. Test DB2 JDBC connectivity from the Administration Console to the WASV7DB database.
  15. Install and configure the DefaultApplication sample for the Snoop and Hit Count samples.
  16. Configure host aliases for the default virtual host.
  17. Perform Snoop and Hit Count tests using the sample application running on individual members of cluster by specifying host:port numbers explicitly.
  18. Perform Snoop and Hit Count tests using IBM HTTP Server, its plug-in, and the cluster topology.

Run IBM MobileFirst on the Network Deployment Profile

This section outlines the steps you must complete to install, configure, and validate the deployment of IBM MobileFirst applications named IBM_Worklight_Console and IBM_Application_Center to a clustered network deployment topology.

  1. Install IBM MobileFirst software in a cluster topology using IBM Installation Manager.
  2. Update IBM MobileFirst software in the cluster topology using IBM Installation Manager.
  3. Define a Worklight shared library for the cluster scope for the IBM Worklight Console to use:
    1. Click Worklight Platform Library > worklight-jee-library.jar.
    2. Select the Class Loading > Use an isolated class loader for this shared library option.
  4. Define the WebSphere environment variable for the cluster scope:
    1. For Name, type WORKLIGHT_INSTALL_DIR.
    2. For Value, type C:/I/WLServer_1.
    3. For Description, type Worklight Server Install Directory
  5. Define custom properties for cluster member WebSphere Application Server Java Virtual Machines (JVMs) for MobileServerA:
    1. Navigate to WebSphere application server clusters > MobileCluster > Cluster members > MobileServerA > Process definition > Java Virtual Machine > Custom properties.
    2. Click New.
    3. For Name, type worklight.home.
    4. For Value, type ${USER_INSTALL_ROOT}/servers/MobileServerA/worklight.home.
    5. For Description, type C:/I/WAS/profiles/MobileNodeA/servers/MobileServerA/worklight.home.
    6. Click Apply.
    7. Click New.
    8. For Name, type android.aapt.
    9. For Value, type C:/I/WLServer_1/ApplicationCenter/tools/android-sdk/bin.windows-x86/aapt.exe.
    10. For Description, type Android Tool Location.
    11. Click Apply.
    12. Repeat steps a thru k for MobileServerB.
  6. Define a custom property for cluster member Application Server Web Container:
    1. Navigate to WebSphere application server clusters > MobileCluster > Cluster members > MobileServerA > Web container > Custom properties.
    2. Click New.
    3. For Name, type com.ibm.ws.webcontainer.invokeFlushAfterService.
    4. Value, type false.
    5. For Description, type See http://www-01.ibm.com/support/docview.wss?uid=swg1PM50111.
    6. Click Apply.
    7. Repeat steps a through g for MobileServerB.
  7. Define Worklight data sources named WRKLGHT, WLREPORT, and APPCNTR, and test connectivity using the Administrative Console:
    1. For the WRKLGHT data source, define the following:
      • For Scope, type cells:MobileCellDMgr:clusters:MobileCluster.
      • For Data source name, type Worklight database.
      • For JNDI name, type jdbc/WorklightDS.
      • For Select an existing JDBC provider, type DB2 Universal JDBC Driver Provider (XA).
      • For Driver type, type 4.
      • For Database name, type WRKLGHT.
      • For Server name, type BASE-WIN2K8X64.
      • For Port number type 50000.
      • Select the Use this data source in container managed persistence (CMP) check box.
      • For Authentication alias for XA recovery, type MobileNodeDMgr/db2alias.
      • For Component-managed authentication alias, type MobileNodeDMgr/db2alias.
      • For Mapping-configuration alias, type DefaultPrincipalMapping.
      • For Container-managed authentication alias, type MobileNodeDMgr/db2alias.
    2. For the WLREPORT data source, define the following:
      • For Scope, type cells:MobileCellDMgr:clusters:MobileCluster.
      • For Data source name, type Worklight reports database
      • For JNDI name, type jdbc/WorklightReportsDS.
      • For Select an existing JDBC provider, type DB2 Universal JDBC Driver Provider (XA).
      • For Driver type, type 4.
      • For Database name, type WLREPORT.
      • For Server name, type BASE-WIN2K8X64.
      • For Port number type 50000.
      • Select the Use this data source in container managed persistence (CMP) check box.
      • For Authentication alias for XA recovery, type MobileNodeDMgr/db2alias.
      • For Component-managed authentication alias, type MobileNodeDMgr/db2alias.
      • For Mapping-configuration alias type DefaultPrincipalMapping.
      • For Container-managed authentication alias, type MobileNodeDMgr/db2alias.
    3. For the APPCNTR data source, define the following:
      • For Scope type cells:MobileCellDMgr:clusters:MobileCluster.
      • For Data source name, type Application Center database.
      • For JNDI name, type jdbc/AppCenterDS.
      • For Select an existing JDBC provider, type DB2 Universal JDBC Driver Provider (XA).
      • For Driver type, type 4.
      • For Database name, type APPCNTR.
      • For Server name, type BASE-WIN2K8X64.
      • For Port number, type 50000.
      • Select the Use this data source in container managed persistence (CMP) check box.
      • For Authentication alias for XA recovery, type MobileNodeDMgr/db2alias.
      • For Component-managed authentication alias, type MobileNodeDMgr/db2alias.
      • For Mapping-configuration alias, type DefaultPrincipalMapping.
      • For Container-managed authentication alias, type MobileNodeDMgr/db2alias,
  8. Install the Worklight application worklight.war:
    1. For Applications select Install New Middleware Application.
    2. For application type, select Java 2 Platform, Enterprise Edition, and then click Next.
    3. For Local file system, click Full path > Choose File >, enter C:\I\WLServer_1\WorklightServer\worklight.war, then click Next.
    4. For How do you want to install the application, select Detailed – Show all installation options and parameters, click Next, and then click Continue.
    5. For Directory to install application, type $(APP_INSTALL_ROOT)/MobileCellDMgr.
    6. For Application name, type IBM_Worklight_Console, and then click Next.
    7. For Map Shared Libraries, select,IBM_Worklight_Console, select Reference shared libraries, select Worklight Platform Library, click the forward arrow icon, click OK, then click Next three times.
    8. For Map context roots for web modules, type /worklight, then click Next three times.
    9. For Review Summary, click Finish, and then click Save.
    10. For Specify Enterprise Applications, click IBM_Worklight_Console > Class loader > Class loader order > Classes loaded with local class loader first (parent last).
    11. For Specify Enterprise Applications, click IBM_Worklight_Console > Manage Modules > applicationcenter.war > class loader order > Classes loaded with local class loader first (parent last).
    12. For Specify WebSphere application server clusters, click MobileCluster > Cluster members > MobileServerA > Server-specific Application Settings > Classloader policy > Single.
    13. For Specify WebSphere application server clusters, click MobileCluster > Cluster members > MobileServerB > Server-specific Application Settings > Classloader policy > Single.
    14. Start the application, making sure it starts in the cluster.
  9. Create a Worklight Application Center user group and user:
    1. Click Users and Groups > Manage Groups > Create. Then, enter the following:
      • For Group name, type appcentergrp.
      • For Description, type the group of users for Worklight Application Center.
    2. Click Create.
    3. Click Users and Groups > Manage Users > Create. Then, enter the following:
      • For User ID, type appcenteradmin.
      • For First name, type Administrator.
      • For Last name, type User.
      • Leave E-mail blank.
      • For Password, type admin.
    4. Click Group Membership > Search > appcentergrp > Add. Click Close, then click Create.
  10. Install applicationcenter.war in Worklight Application Center:
    1. Click Applications > Install New Middleware Application.
    2. For Select application type, choose Java 2 Platform, Enterprise Edition, and then click Next.
    3. Click Local file system > Full path > Choose File, then enter C:\I\WLServer_1\ApplicationCenter\console\applicationcenter.war. Click Next.
    4. For How do you want to install the application, choose Detailed – Show all installation options and parameters. Click Next, then click Continue.
    5. For Directory to install application, type $(APP_INSTALL_ROOT)/MobileCellDMgr.
    6. For Application name, type IBM_Application_Center, then click Next seven times.
    7. Click Map resource references to resources > Target Resource JNDI Name, enter jdbc/AppCenterDS, then click Next twice.
    8. Click Map context roots for Web modules > ApplicationCenter, then type /applicationcenter.
    9. For Map security roles to users or groups, click appcenteruser > Map Groups > Search. For Available, type appcentergrp, click the forward arrow icon, click OK, and then click Next.
    10. For Specify Enterprise Applications, click IBM_Application_Center > Class loader > Class loader order > Classes loaded with local class loader first (parent last).
    11. For Specify Enterprise Applications, click IBM_Application_Center > Manage Modules > applicationcenter.war > class loader order > Classes loaded with local class loader first (parent last).
    12. Start the application, making sure it starts in the cluster.

Figure 5 shows the successful configuration of an IBM MobileFirst application running in the WebSphere Application Server cluster MobileCluster.

Figure 5. IBM MobileFirst application running in the WebSphere Application Server cluster MobileCluster
Image showing the app running in the MobileCluster cluster

Enable end-to-end SSL communications for the Network Deployment Profile

The following section details the process for establishing end-to-end SSL communications from various components of the distributed, multitiered network deployment topology architecture. Table 1 summarizes the configuration.

Table 1. Summary of configuration actions performed
StepFile detailsPersonal certificatesSigner certificates
1C:\I\IHS\ssl\IHSADMINSSL.kdbIHSAdminSelfSignedCertCellKeyPersonalDefaultCertificate
CellTrustSignerRootCertificate
IHSSSLSelfSignedCertificate
2C:\I\IHS\ssl\IHSSSL.kdbIHSSSLSelfSignedCertIHSAdminSelfSignedCert
IHSPluginCMSPersonalSelfSignedCertificate
Pre-populated Certificates from Entrust.net, Thawte and VeriSign
3C:\I\Plugins\config\webserver1\plugin-key.kdbIHSPluginCMSPersonalSelfSignedCertCellKeyPersonalDefaultCertificate
CellTrustSignerRootCertificate
NodeAKeyPersonalDefaultCertificate
NodeATrustSignerRootCertificate
NodeBKeyPersonalDefaultCertificate
NodeBTrustSignerRootCertificate
IHSAdminSSLSelfSignedCertificate
IHSSSLSelfSignedCertificate
4C:\I\WAS\profiles\MobileNodeDMgr\config\cells\MobileCellDMgr\trust.p12root
ihsadminsslselfsignedcert
ihssslselfsignedcert
ihsplugincmspersonalselfsignedcertificate
5C:\I\WAS\profiles\MobileNodeA\config\cells\MobileCellDMgr\trust.p12root
ihsadminsslselfsignedcert
ihssslselfsignedcert
ihsplugincmspersonalselfsignedcertificate
6C:\I\WAS\profiles\MobileNodeB\config\cells\MobileCellDMgr\trust.p12root
ihsadminsslselfsignedcert
ihssslselfsignedcert
ihsplugincmspersonalselfsignedcertificate

Complete the following steps to configure SSL communications:

  1. Set up IBM HTTP Administrative Server SSL communication:
    1. Create the C:\I\IHS\SSL\IHSADMINSSL.kdb CMS key database.
    2. Create the IHSAdminSelfSignedCert certificate:
      • For Key Label, type IHSAdminSelfSignedCert.
      • For Key Size, type 2048.
      • For Common Name, type BASE-WIN2K8X64.
      • For Organization, type IBM.
      • For Organizational Unit, type S&D.
      • For Locality, type LEESBURG.
      • For State/Province, type VA.
      • For Zipcode, type 20176.
      • For Country or region, type US.
      • For IP Address, type 192.168.93.129.
    3. Extract the IHSAdminSelfSignedCert certificate in Base64-encoded ASCII data with extension named IHSAdminSSLSelfSignedCert.arm.
  2. Set up IBM HTTP Server SSL communication:
    1. Create the C:\I\IHS\SSL\IHSSSL.kdb CMS key database.
    2. Create the IHSSSLSelfSignedCert certificate:
      • For Key Label, type IHSSSLSelfSignedCert.
      • For Key Size, type 2048.
      • For Common Name, type BASE-WIN2K8X64.
      • For Organization, type IBM.
      • For Organizational Unit, type S&D.
      • For Locality, type LEESBURG.
      • For State/Province, type VA.
      • For Zipcode, type 20176.
      • For Country or region, type US.
      • For IP Address, type 192.168.93.129.
    3. Extract the IHSSSLSelfSignedCert certificate in Base64-encoded ASCII data with extension named IHSSSLSelfSignedCert.arm.
  3. Set up IBM HTTP Server plug-in SSL communication:
    1. Edit the C:\I\Plugins\config\webserver1\plugin-key.kdb CMS key database.
    2. Create the IHSPluginCMSPersonalSelfSignedCertificate certificate:
      • For Key Label, type IHSPluginCMSPersonalSelfSignedCertificate.
      • For Key Size, type 2048.
      • For Common Name, type BASE-WIN2K8X64.
      • For Organization, type IBM.
      • For Organizational Unit, type S&D.
      • For Locality, type LEESBURG.
      • For State/Province, type VA.
      • For Zipcode, type 20176.
      • For Country or region, type US.
      • For IP Address, type 192.168.93.129.
    3. Extract the IHSPluginCMSPersonalSelfSignedCertificate certificate in Base64-encoded ASCII data with extension named IHSPluginCMSPersonalSelfSignedCertificate.arm. See Figure 6 for populated signer certificates in the plugin-key.kdb CMS key database using the IBM Key Management tool, iKeyman (see Resources).
      Figure 6. Populated signer certificates in the plugin-key.kdb CMS key database
      Image showing the populated signer cerficates in the plugin-key.kdb CMS key database
  4. Extract Network Deployment Profile personal and signer certificates for the deployment manager and cluster member servers:
    1. Edit the C:\I\was\profiles\MobileNodeDMgr\config\cells\MobileCellDMgr\key.p12 PKCS12 Key Store.
    2. Extract the Base64-encoded ASCII data-formatted default personal certificate.
    3. Edit the C:\I\was\profiles\MobileNodeDMgr\config\cells\MobileCellDMgr\trust.p12 PKCS12 Trust Store.
    4. Extract the Base64-encoded ASCII data-formatted root signer certificate.
    5. Edit the C:\I\was\profiles\MobileNodeA\config\cells\MobileCellDMgr\key.p12 PKCS12 Key Store.
    6. Extract the Base64-encoded ASCII data-formatted default personal certificate.
    7. Edit the C:\I\was\profiles\MobileNodeA\config\cells\MobileCellDMgr\trust.p12 PKCS12 Trust Store.
    8. Extract the Base64-encoded ASCII data-formatted root signer certificate.
    9. Edit the C:\I\was\profiles\MobileNodeB\config\cells\MobileCellDMgr\key.p12 PKCS12 Key Store.
    10. Extract the Base64-encoded ASCII data-formatted default personal certificate.
    11. Edit the C:\I\was\profiles\MobileNodeB\config\cells\MobileCellDMgr\trust.p12 PKCS12 Trust Store.
    12. Extract the Base64-encoded ASCII data-formatted root signer certificate.
  5. Add signer certificates to the CMS Key database stores and trust stores to establish trusted SSL communication relationships:
    1. Add CellKeyPersonalDefaultCertificate, CellTrustSignerRootCertificate, and IHSSSLSelfSignedCertificate signer certificates to the C:\I\IHS\SSL\IHSADMINSSL.kdb CMS Key database.
    2. Add IHSAdminSSLSelfSignedCertificate and IHSPluginCMSPersonalSelfSignedCertificate signer certificates to the C:\I\IHS\SSL\IHSSSL.kdb CMS Key database.
    3. Add CellKeyPersonalDefaultCertificate, CellTrustSignerRootCertificate, NodeAKeyPersonalDefaultCertificate, NodeATrustSignerRootCertificate, NodeBKeyPersonalDefaultCertificate, NodeBTrustSignerRootCertificate, IHSAdminSSLSelfSignedCertificate, and IHSSSLSelfSignedCertificate signer certificates to the C:\I\Plugins\config\webserver1\plugin-key.kdb CMS Key database.
    4. Add IHSPluginCMSPersonalSelfSignedCertificate, IHSAdminSSLSelfSignedCertificate, and IHSSSLSelfSignedCertificate signer certificates to the C:\I\was\profiles\MobileNodeDMgr\config\cells\MobileCellDMgr\trust.p12 PKCS12 Trust Store.
    5. Add IHSPluginCMSPersonalSelfSignedCertificate, IHSAdminSSLSelfSignedCertificate, and IHSSSLSelfSignedCertificate signer certificates to the C:\I\was\profiles\MobileNodeA\config\cells\MobileCellDMgr\trust.p12 PKCS12 Trust Store.
    6. Add IHSPluginCMSPersonalSelfSignedCertificate, IHSAdminSSLSelfSignedCertificate, and IHSSSLSelfSignedCertificate signer certificates to the C:\I\was\profiles\MobileNodeB\config\cells\MobileCellDMgr\trust.p12 PKCS12 Trust Store.

Enable FIPS 140-2 in the Network Deployment Profile

This section provides the steps to enable FIPS 140-2 configuration from the end-to-end infrastructure perspective:

  1. Prepare the platform for FIPS 140-2 enforcement on a computer running Windows Server® 2008 R2 Enterprise:
    1. Click Start.
    2. In Local Security Policy, expand Security Settings > Local Policies > Security Options.
    3. In System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing, click the Local Security Setting tab.
    4. Select the Enabled option, then click OK (Figure 7).
      Figure 7. Local security policy configuration for FIPS 140-2 enforcement in Windows Server
      Image showing the Windows Server local security policy
  2. Start a WebSphere Application Server Network Deployment Profile instance.
  3. Connect the browser Administrator Console to the deployment manager server.
  4. Configure administration and the user-deployed application security policy:
    1. Click Security > Global Security.
    2. Enable administrative security.
    3. Enable application security.
  5. Configure the FIPS 140-2-compliant Java cryptography engine to enforce FIPS 140-2 compliance policy by clicking Security > SSL certificate and key management > Manage FIPS > Enable FIPS 140-2.
  6. Edit the server-side java.security configuration file by adding the IBMJCEFIPS provider:
    1. Back up C:\I\WAS\java\jre\lib\security\java.security, and move the copy to a safe location.
    2. Modify the lines:

      com.ibm.crypto.fips.provider.IBMJCEFIPS <-- Before
      			com.ibm.crypto.fips.provider.IBMJCE

      . . . to read as follows:


      security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS
      security.provider.2=com.ibm.crypto.provider.IBMJCE
      security.provider.3=com.ibm.jsse2.IBMJSSEProvider2
      security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
      security.provider.5=com.ibm.security.cert.IBMCertPath
      security.provider.6=com.ibm.security.cmskeystore.CMSProvider
      security.provider.7=com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl
      security.provider.8=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
      security.provider.9=com.ibm.security.sasl.IBMSASL
      security.provider.10=com.ibm.xml.crypto.IBMXMLCryptoProvider
      security.provider.11=com.ibm.xml.enc.IBMXMLEncProvider
      	security.provider.12=org.apache.harmony.security.provider.PolicyProvider
  7. Edit the client SSL configuration file:
    1. Back up C:\I\WAS\profiles\MobileNodeDMgr\properties\ssl.client.props, and move the copy to a safe location.
    2. Edit the contents of C:\I\WAS\profiles\MobileNodeDMgr\properties\ssl.client.props.
    3. Set com.ibm.security.useFIPS=true.
    4. Set com.ibm.ssl.protocol=TLS.
    5. Repeat steps a and b for C:\I\WAS\profiles\MobileNodeA\properties\ssl.client.props and C:\I\WAS\profiles\MobileNodeB\properties\ssl.client.props.
  8. Edit the IBM HTTP Server configuration file:
    1. Back up C:\I\IHS\Conf\httpd.conf, and move the copy to a safe location.
    2. Add the directive SSLFIPSEnable.
  9. Edit the IBM HTTP Administrative Server configuration file:
    1. Back up C:\I\IHS\Conf\admin.conf, and move the copy to a safe location.
    2. Add the directive SSLFIPSEnable.
  10. Customize the Worklight Server for the Network Deployment Profile on the deployed file system.

    Figure 8 shows details of Worklight Server customization for the MobileCluster deployed applications.

    Figure 8. Worklight Server customization for MobileCluster deployment
    Image showing Worklight Server customization for MobileCluster deployment
  11. Restart the Network Deployment Profile (including cluster member application servers, node agents, and deployment manager in that specific order).

Enable logging, tracing, and instrumentation for the Network Deployment Profile

In this section, review the process you use to perform end-to-end, fine-grained logging, tracing, and instrumentation collection to validate the protocol handshake messages.

  1. Log SSL request information to the IBM HTTP Server access log by using SSL environment variables within the C:\I\IHS\conf\httpd.conf configuration file:
    • LogLevel debug
    • LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    • LogFormat "%h %l %u %t \"%r\" %>s %b" common
    • LogFormat "%h %l %u %t \"%r\" %>s %b %{HTTPS}e %{SSL_CIPHER}e %{SSL_CLIENT_DN}e" SSL
    • LogFormat "%{Referer}i -> %U" referer
    • LogFormat "%{User-agent}i" agent
  2. Enable the logging level to debug with custom logging for IBM HTTP Administrative Server within the C:\I\IHS\conf\admin.conf configuration file:
    • LogLevel debug
    • LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    • LogFormat "%h %l %u %t \"%r\" %>s %b" common
    • LogFormat "%{Referer}i -> %U" referer
    • LogFormat "%{User-agent}i" agent
  3. Enable the logging level to error scope in the plug-in configuration file identified by C:\I\Plugins\config\webserver1\plugin-cfg.xml:
    • <Log LogLevel="Error" Name="C:\I\Plugins/logs/webserver1/http_plugin.log"/>
  4. Enable JVM tracing for tracking the SSL handshakes in application JVMs:
    1. In Application servers > MobileServerA > Process definition > Java Virtual Machine > Generic JVM arguments, use the value Djavax.net.debug=true.
    2. In Application servers > MobileServerA > Process definition > Java Virtual Machine > Custom properties, for javax.net.debug, use the value ssl:record:plaintext:handshake:verbose:keygen:session:defaultctx:sslctx:sessioncache:keymanager:trustmanager.
    3. In Application servers > MobileServerB > Process definition > Java Virtual Machine > Generic JVM arguments, use the value Djavax.net.debug=true.
    4. In Application servers > MobileServerB > Process definition > Java Virtual Machine > Custom properties, for javax.net.debug, use the value ssl:record:plaintext:handshake:verbose:keygen:session:defaultctx:sslctx:sessioncache:keymanager:trustmanager.

      Figure 9 shows the logging, tracing, and instrumentation-enabled MobileCluster cluster member server A.

      Figure 9. Logging, tracing, and instrumentation for cluster member A
      Image showing logging, tracing, and instrumentation for cluster member A

      Figure 10 shows the logging, tracing, and instrumentation-enabled MobileCluster cluster member server B.

      Figure 10. Logging, tracing, and instrumentation for cluster member B
      Image showing logging, tracing, and instrumentation for cluster member B
  5. Enable granular logging and tracing in WebSphere Application Server containers:
    1. In Logging and tracing > MobileServerA > Diagnostic trace service, use the value ${SERVER_LOG_ROOT}/Base-Win2k8x64SSLTrace.log.
    2. In Logging and tracing > MobileServerA > Change log detail levels, use the value *=info: com.worklight.adapters.*=all: com.worklight.server.*=all: com.worklight.report.*=all: com.worklight.integration.*=all: com.worklight.database.*=all: com.worklight.core.*=all: com.worklight.console.*=all: com.worklight.common.*=all: com.worklight.gadgets.*=all: com.ibm.ws.jdbc.*=all: Transaction=all: RRA=all: WAS.j2c=all.
  6. Repeat the above steps for the MobileServerB, dmgr, nodeagent > MobileNodeA, nodeagent > MobileNodeB server processes.

Test IBM MobileFirst for the Network Deployment Profile

This section outlines the procedure you use to test the mobile application deployed to the clustered topology to validate round-robin load balancing and graceful degradation by failover semantics in the infrastructure.

  1. Start the deployment manager profile:
    1. Ensure that the DB2 instance is running.
    2. Ensure that the IBM HTTP Server service instance is running.
    3. Ensure that the IBM HTTP Administrator Server service instance is running.
    4. Start the deployment manager process.
    5. Start the node agent processes for MobileNodeA and MobileNodeB, one at a time.
    6. Start cluster member application server processes—MobileServerA and MobileServerB—one at a time.
  2. Perform a Snoop test by pointing your browser to:
    • https://localhost:9444/snoop
    • https://localhost:9445/snoop
    • https://localhost:443/snoop

    Figure 11 shows the Snoop servlet running in the cluster.

    Figure 11. The Snoop servlet running in the cluster
    Image showing the Snoop servlet running in the cluster
  3. Perform Hit Count test by pointing your browser to:
    • https://localhost:9444/hitcount
    • https://localhost:9445/hitcount
    • https://localhost:443/hitcount

    Figure 12 shows the Hit Count sample running in the cluster.

    Figure 12. The Hit Count sample running in the cluster
    Image showing the Hit Count sample running in the cluster
  4. Launch the Worklight Console by pointing your browser to:
    • https://localhost:9444/worklight/console
    • https://localhost:9445/worklight/console
    • https://localhost:443/worklight/console

    Figure 13 shows the Worklight Console running in the cluster.

    Figure 13. The Worklight Console running in the cluster
    Image showing the Worklight Console running in the cluster
  5. Launch Worklight Application Center by pointing your browser to:
    • https://localhost:9444/applicationcenter
    • https://localhost:9445/applicationcenter
    • https://localhost:443/applicationcenter

    Figure 14 shows Worklight Application Center running in the cluster.

    Figure 14. Worklight Application Center running in the cluster
    Image showing Worklight Application Center running in the cluster
  6. Perform clustered, round-robin load-balanced, failover configuration testing, with both cluster members running:
    1. Go to https://localhost:443/worklight/console.
    2. On Android, go to https://localhost/worklight/apps/services/preview/WLv505FIPS140_2Example/android/1.0/default/WLv505FIPS140_2Example.html.
    3. Log out.
    4. Call the protected DB2 SQL adapter procedure.
    5. For Username, type admin.
    6. For Password, type admin.
    7. Click OK.
    8. Call the protected DB2 SQL adapter procedure, then click OK.
    9. Log out.
    10. Perform Android Emulator testing.
    11. Perform tablet/smartphone device testing.

    Figure 15 shows the successful execution of the mobile application running in the cluster.

    Figure 15. Preview testing of the mobile application running in the cluster
    Image showing preview testing of the mobile application running in the cluster

    Figure 16 shows the successful execution of the mobile application running in the cluster with IBM Lightweight Third-party Authentication (LTPA) token creation.

    Figure 16. Preview testing of the mobile application running: LTPA token creation
    Image showing preview testing of the mobile application with LTPA token creation

    Figure 17 shows the successful execution of the mobile application running in the cluster with LTPA token creation on a subsequent invocation.

    Figure 17. Preview testing of the mobile application running: subsequent invocation
    Image showing the mobile application on subsequent invocation
  7. Perform graceful degradation configuration testing, with one cluster member up and one down:
    1. Stop MobileServerB.
    2. Go to https://localhost:443/worklight/console.
    3. On Android, go to https://localhost/worklight/apps/services/preview/WLv505FIPS140_2Example/android/1.0/default/WLv505FIPS140_2Example.html.
    4. Log out.
    5. Call the protected DB2 SQL adapter procedure.
    6. For Username, type admin.
    7. For Password, type admin.
    8. Click OK.
    9. Call the protected DB2 SQL adapter procedure, then click OK.
    10. Log out.
    11. Perform Android Emulator testing.
    12. Perform tablet/smartphone device testing.
  8. Perform graceful degradation configuration testing, with one cluster member up and one down:
    1. Start MobileServerB.
    2. Stop MobileServerA.
    3. Go to https://localhost:443/worklight/console.
    4. On Android, go to https://localhost/worklight/apps/services/preview/WLv505FIPS140_2Example/android/1.0/default/WLv505FIPS140_2Example.html.
    5. Log out.
    6. Call the protected DB2 SQL adapter procedure.
    7. For Username, type admin.
    8. For Password, type admin.
    9. Click OK.
    10. Call the protected DB2 SQL adapter procedure, then click OK.
    11. Log out.
    12. Perform Android Emulator testing.
    13. Perform tablet/smartphone device testing.
  9. Perform system-down configuration testing, with both cluster members down:
    1. Stop MobileServerB.
    2. Stop MobileServerA.
    3. Go to https://localhost:443/worklight/console.

      You get the message "500 Internal Server Error" (see Figure 18).

      Figure 18. Unavailability of the mobile application in the Worklight Console running in the cluster
      Image showing unavailable of the mobile application
    4. Go to https://localhost:443/snoop.

      You get the message "500 Internal Server Error".

    5. Go to https://localhost:443/hitcount.

      You get the message "500 Internal Server Error".

    Figure 19 shows the mobile application as unavailable in the Worklight Application Center running in the cluster.

    Figure 19. Unavailability of the mobile application in the Worklight Application Center
    Image showing unavailable of the mobile application in Worklight Application Center
  10. Repeat the above test for Worklight Application Center to confirm the same clustered, round-robin load-balanced and failover behavior.
  11. Stop the deployment manager profile:
    1. Stop cluster member application server processes MobileServerA and MobileServerB one at a time.
    2. Stop node agent processes for MobileNodeA and MobileNodeB one at a time.
    3. Stop the deployment manager process.

Verification and validation analysis

This section outlines the approach you use to perform verification and validation of end-to-end SSL communication. The verification and validation approach consists of reviewing and confirming security-enabled request-response flows:

  • From the mobile client to and from IBM HTTP Server;
  • To and from IBM HTTP Server to and from the IBM HTTP Server plug-in;
  • To and from the IBM HTTP Server plug-in to and from the WebSphere Application Server cluster member; and
  • To and from the WebSphere Application Server cluster member to and from the DB2 back end.

Review the IBM HTTP Server (access.log, error.log) and IBM HTTP Administrative Server (admin_access.log) log files, and confirm that the SSL communication flows. Figure 20 shows the IBM HTTP Server access.log file contents.

Figure 20. IBM HTTP Server access.log file
Image showing the IBM HTTP Server access.log file

Figure 21 shows the IBM HTTP Server error.log file contents.

Figure 21. IBM HTTP Server error.log file
Image showing the IBM HTTP Server error.log file

Figure 22 shows the IBM HTTP Server admin_error.log file contents.

Figure 22. IBM HTTP Server admin_error.log file
Image showing the IBM HTTP Server admin_error.log file

Review the http_plugin.log file to confirm that the plug-in is performing load balancing using a simple round-robin routing scheme. Figure 23 shows the contents of the IBM HTTP Server plug-in log file.

Figure 23. IBM HTTP Server plug-in http_plugin.log file
Image showing the IBM HTTP Server plug-in http_plugin.log file

Review the Base-Win2k8x64SSLTrace.log trace files from MobileNodeA, its node agent, MobileNodeB, its node agent, and MobileNodeDMgr processes. Confirm the complete SSL handshake negotiations taking place between client and server components of the mobile application. Confirm that FIPS 140-2 is enabled, as reported by the FIPSManager component. You can see that C:\I\WAS\java\jre\lib\ext\ibmjcefips.jar file logic provides the FIPS provider capability.

Review and confirm the communication flows between Worklight Server and the DB2 back-end server by querying the keyword SQLQuery in the log files. The log file confirms the successful sequence of SQL calls from the Worklight SQLAdapter to the back end and the associated back-end response.


Conclusion

This article showed how to configure Worklight Server for FIPS 140-2 compliance validation and verification as well as set up, configure, and validate a distributed, clustered, multitiered WebSphere Application Server network deployment architecture topology with the current version of WebSphere Application Server and IBM HTTP Server.

You learned how to set up end-to-end, secure SSL communications by creating and configuring trust certificates and relationships. You deployed a mobile application to a security-enabled infrastructure configured to capture fine-grained tracing, logging, and instrumentation. Finally, you verified and validated the end-to-end working of that mobile application for FIPS 140-2 compliance by exercising the mobile client application running on a mobile device, making a request to the mobile server application running in a configured WebSphere infrastructure.

Congratulations on completing this two-part article series!

Acknowledgments

The author gratefully acknowledges the feedback, constructive suggestions, support, and productive teaming from the following IBMers:

  • William D. Dodd, Software Engineer, Mobile Application Platform (bdodd@us.ibm.com)
  • William J. O'Donnell, WebSphere Foundation Security Architect (Bill.ODonnell@us.ibm.com)
  • Ian Robinson, Distinguished Engineer, WebSphere Foundation Chief Architect (ian_robinson@uk.ibm.com)
  • Srinivas R. Sama, Software Engineer, IBM Worklight Support (srsama@us.ibm.com)
  • Tom A. Dressel, Software Engineer, IBM Mobile Foundation/Worklight Support (tdressel@us.ibm.com)
  • Raj Balasubramanian, Senior Software Engineer, Product Architect for IBM Mobility Services (raj_balasubramanian@us.ibm.com)
  • Parviz Behseta, IT Architect, IBM Sales and Distribution (pbehset@us.ibm.com)
  • Mark A. Smith, WebSphere Technical Professional Manager (marksmith@us.ibm.com)

Download

DescriptionNameSize
Application sample, configuration, and log filesarticlebundle_02192013.zip109MB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Mobile development on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Mobile development, WebSphere, Security, DevOps
ArticleID=933891
ArticleTitle=IBM Worklight server configuration for FIPS 140-2 validation and certification, Part 2: Deploying your mobile app on WebSphere Application Server
publish-date=06122013