IBM Worklight server configuration for FIPS 140-2 validation and certification, Part 1: Configuring a server-side WebSphere Application Server infrastructure

In this article, learn the steps for verifying and validating the end-to-end working of your mobile application for Federal Information Processing Standard (FIPS) 140-2 (Cryptographic Module Validation Program) compliance. Steps include installing the prerequisite products (IBM® Worklight Studio, Worklight Server deployed to an IBM WebSphere® Application Server Liberty Profile, and a Base Profile), enabling server-side, end-to-end security; configuring the server-side infrastructure for FIPS 140-2 compliance; and finally instrumenting, collecting, analyzing, and validating FIPS 140-2 compliance from the logging, tracing, and instrumentation facilities of the WebSphere infrastructure.

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.



28 May 2013

Also available in Chinese

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.

The Federal Information Processing Standard (FIPS) Publication 140-2 from the National Institute of Standards and Technology (NIST) is a U.S. Federal Government computer security standard used to certify cryptographic methods employed when participating computers are communicating using a pervasive, public, and insecure infrastructure for information security (confidentiality, integrity, authentication, non-repudiation, and so on. See Resources for more details.

Typical FIPS 140-2-compliant programs invoke FIPS-approved cryptographic functions for confidentiality, integrity, and message digest services to meet FIPS 140-2 requirements and use APIs to access underlying FIPS 140-2 crypto libraries. Transport eLayer Security (TLS) and Secure Socket Layer (SSL) are cryptographic protocols used widely to provide information security over open and public networks such as the Internet.

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.

The IBM® Worklight platform consists of:

  • IBM Worklight Studio for developing native, hybrid, and standard mobile applications
  • IBM Worklight Server for testing and deploying those mobile applications
  • The IBM Worklight Device Runtime Components, which run on mobile devices such as smartphones and tablets
  • The IBM Worklight Console, which includes a browser user interface for administering mobile applications and adapters
  • The IBM Worklight Application Center for storing and sharing mobile applications across an enterprise

Mobile applications consist of application resources such as images, string constants, colors, drawings, animations, themes, menus, layouts, and adapters. You can protect mobile applications running on the Worklight platform from unauthorized access by using the Worklight authentication and authorization framework.

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.

Liberty Profile v8.5.0.1, at its core, is an OSGi technology-founded lightweight, fast, dynamic, flexible, composable application development and runtime environment engineered to work with WebSphere Application Server Developer Tools for Eclipse. Liberty Profile is capable of provisioning features minimally needed to support deployed applications dynamically, without having to restart the server. Liberty Profile supports a subset of Java™ Platform, Enterprise Edition (Java EE) version 6 technology standards. Figure 1 shows the Liberty Profile architecture.

Figure 1. Liberty Profile architecture
Image showing the Liberty Profile architecture

WebSphere Application Server Base Profile v8.5.0.1, at its core, is an application server platform on which you can deploy Java business applications. The application server platform provides database connectivity, threading, and application management services. When configured, each base profile assumes a unique runtime environment hosting one or more business applications and providing the services required to support the hosted applications. You manage each Base Profile through a browser-based administrative management console, and you can install multiple instances of independent Base Profiles on a single system. Figure 2 shows the Base Profile architecture.

Figure 2. Base Profile architecture
Image showing the Base Profile architecture

Use case architecture

Figure 3 shows the end-to-end use case architecture. Requests originate from mobile client devices—smartphones or tablets powered by the Google Android, Apple iOS, RIM Blackberry, or Windows® mobile platform. Client requests make it to the server side via Wi-Fi or cellular telecommunications provider networks and public Internet service provider networks. Once on the server side, the request flows through a WebSphere Application Server (Liberty and Base Profiles) security infrastructure that is hosting the Worklight Server application. Subsequent successfully authenticated requests flow to a back-end IBM DB2® SQL database server, shown in Figure 3. The operating system platform itself (Windows 7 64-bit) is configured for FIPS 140-2 policy enforcement (see Resources for a link to more information).

Figure 3. End-to-end use case architecture diagram
Image showing the end-to-end use case architecture diagram

WebSphere Application Server is Java EE middleware infrastructure software that supports a variety of well-understood server authentication and trust models to provide security for application resources such as enterprise architecture and web archive (WAR) as well as service artifacts. The WebSphere Application Server enterprise container contract enforces the security quality-of-service attributes configured when application security is enabled for Worklight and other deployed enterprise applications. This security configuration option affords integration with existing third-party Single Sign-on products to secure the Java EE container.

For this article's use case, securing resources in this manner is an appropriate choice, because the mobile devices are trustworthy (the Samsung tablet, Verizon Android smartphone, and Apple iPad device used in developing this article are IBM-owned, certified, and provided), and the server-side resources are provided only to trusted mobile application requests. Worklight provides other means of securing resources when deployed in WebSphere Application Server environments. To protect application resources, this article's use case enables WebSphere Application Server application security, using a traditional WebSphere Application Server authentication and trust model to secure a Worklight WAR application running on top of WebSphere Application Server.

Because Worklight features an extensible authentication model as its core capability, mobile applications developed using the Worklight platform with a Worklight Server application running on top of WebSphere Application Server can have user authentication configured to capitalize on Lightweight Third-Party Authentication (LTPA) tokens that the underlying WebSphere Application Server runtime provides for user authentication. This is what the article use case is designed to demonstrate.

In the server-side, security-enabled mode of configuration, when a user launches the mobile client application on a mobile device for the first time, the server-side infrastructure challenges the mobile client application for user credentials. The mobile client can provide the user credentials to the server using a login form. Figure 4 shows this initial authentication request-response flow.

Figure 4. Initial authentication request-response sequence
Image showing the initial authentication request-response sequence

If the user credentials received from the mobile client are authenticated successfully on the server side, the server generates an LTPA token, with the security context encapsulated and returned to the mobile client as an LTPA cookie. The client uses the LTPA cookie in subsequent calls to the server. Figure 5 shows this subsequent authenticated request-response flow.

Figure 5. Authenticated subsequent request-response sequence
Image showing the authenticated subsequent request-response sequence

When the user clicks Call protected DB2 SQL adapter procedure, the onclick event invokes a retrieveUsecase() procedure on the server side. This procedure is implemented as a function call in WLv505FIPS140_2Example.js. The function call identifies the adapter involved, the adapter procedure to call, and the adapter procedure parameters to pass in. This function also identifies the callback functions to call upon successful or unsuccessful invocation of adapter procedure.

The adapter procedure connects to the DB2 database FIPSDB with the correct DB2 login credentials and the DB2 schema to retrieve the requested information from a matching row filtered by a where clause in the SQL statement ["SELECT CLIENT, CLIENTTYPE, MIDDLEWARE, SERVEROS, SERVERPROFILE, BACKEND, AUTHORS, REMARKS FROM DB2ADMIN.USECASES WHERE SEQNO = ?"]. The successfully retrieved information from the back-end DB2 instance is passed on to the client in the JavaScript Object Notation (JSON)-formatted response. The DB2 login credential information is shown in the clear, but you can encode it. Figure 6 shows the DB2 FIPSDB database's USECASES table schema definition.

Figure 6. The FIPSDB DB2 database USECASES table definition
Image showing the FIPSDB DB2 database USECASES table definition

Figure 7 shows the populated USECASES table, which consists of nine rows.

Figure 7. USECASES table data
Image showing USECASES table data

As part of the FIPSDBDB2SQLAdapter definition, the <loadConstraints> element defines the maximum load exerted on a back-end application by setting the maximum number of concurrent requests that can be performed on the system. By default, this value is set to 5.

Worklight queues incoming service requests from Worklight applications. Although the number of concurrent requests is below the maximum, Worklight forwards the requests to the back-end application according to their order in the queue. If the number of concurrent requests is above the maximum, Worklight waits until an already handled request is finished before servicing the next one in the queue. If a request waits in the queue for longer than the timeout configured in the procedure, Worklight removes it from the queue and returns a Request Timed Out exception to the caller (by default, 30 seconds).

When a user clicks Logout, the onclick event invokes the client logout from the WASLTPARealm security realm on the server side, and—upon successful logout—the server-side logic reloads the application. This logic releases/frees up the LTPA token previously created and cached.

The source file WLv505FIPS140_2Example.html features two HTML fragments identified by AppBody and AuthBody identifiers. This source file also includes the WASLTPARealmChallengeHandler.js JavaScript source file. This file defines functions named WASLTPARealmChallengeHandler.isCustomResponse, WASLTPARealmChallengeHandler.handleChallenge, WASLTPARealmChallengeHandler.submitLoginForm, WASLTPARealmChallengeHandler.submitLoginFormCallback, WASLTPARealmChallengeHandler.submitFailure, and WASLTPARealmChallengeHandler.submitSuccess. The Worklight Device Runtime Components running on the mobile devices invokes these functions in response to Worklight Server communication messages; they are not meant to be invoked directly by application logic. Infrastructure logic manages the display of either AppBody (upon successful authentication) or AuthBody (when challenge is served, requiring that a login form be presented to collect user credentials) based on logic provided in the WASLTPARealmChallengeHandler.js JavaScript source file and the underlying client-server communication messages. For more details on WASLTPARealmChallengeHandler.js logic, see Resources.

In the implementation of this article's use case, configuration files define the following attributes. The brief descriptions are helpful for understanding the relevant concepts in use case implementation. For detailed explanations, please refer to Resources.

  • Security Test = "WASLTPA-securityTest".WASLTPA-securityTest is a security test that was created to define security configurations to protect Worklight application resources, such as an adapter procedure named getUsecase in the WASLTPA security realm.
  • Realm = "WASLTPARealm".WASLTPARealm is an authentication realm that protects resources, such as an adapter procedure named getUsecase.
  • Device Provisioning ="wl_deviceNoProvisioningRealm". This option ensures that when a mobile application runs for the first time on a deployed mobile device, the process for obtaining a security certificate from the Worklight Server does not take place.
  • loginModule. A login module validates client credentials received from an authenticator. com.worklight.core.auth.ext.FormBasedAuthenticator presents a login form with user name and password entry fields as well as Submit and Cancel buttons. The form is used to authenticate the user. com.worklight.core.auth.ext.NonValidatingLoginModule accepts any user name-password combination. com.worklight.core.auth.ext.SingleIdentityLoginModule grants access to a single user whose identity is defined in the worklight.properties file—either in the clear or encoded.

Figure 8 shows the authenticated user request flowing to the back-end DB2 database server from the Worklight Server SQLAdapter module logic, with the Worklight Server deployed on top of either a WebSphere Application Server Liberty or Base Profile infrastructure. The Worklight SQLAdapter definition provides the back-end connectivity options related to authentication information, number of concurrent requests to handle, and the timeout parameter value (explained previously).

Figure 8. Authenticated downstream flow: Worklight-DB2 database server exchange
Image showing the authenticated Worklight-DB2 database server exchange

Figure 9 shows a sequence diagram that captures all possible and relevant interactions among user, client, and server roles for the use case at hand. The interactions are represented as a sequence of messages flowing between components as time progresses.

Figure 9. Sequence diagram for the use case
Image showing the sequence diagram for the use case

Figure 10 shows one of the value-adds of Worklight Server in its function as a standards-based middleware software product. Worklight Server receives the request from mobile devices using the lightweight JSON/HTTP format and responds to mobile clients in the same format in a response flow. Worklight Server can reach out to multiple back-end sources for multi-source mashups and aggregations. Worklight Server can also auto-translate native responses received from back-end systems to JSON format.

Figure 10. Worklight Server middleware role
Image showing the Worklight server middleware role

Figure 11 shows the SSL handshake exchange between the Worklight client application running on a mobile device and Worklight Server running on an enterprise infrastructure with the FIPS 140-2 policy enabled and enforced.

Figure 11. SSL message handshake
Image showing the SSL message handshake

Use case implementation approach

The Worklight platform primarily consists of Worklight Studio, Worklight Server, the Worklight Device Runtime Components, the Worklight Console, and a Worklight Application Center. You can use Worklight Studio to develop cross-platform portable, multiplatform mobile applications that use HTML5, Cascading Style Sheets version 3 (CSS3), and JavaScript web technologies. The Worklight platform programming model supports HTML (web), hybrid, and native mobile application development. Worklight Studio supports the Worklight programming model, featuring integration with the open source Apache Cordova API; tooling support for popular third-party UI frameworks such as JQuery, Sencha Touch, and Dojo Mobile; and integration with native software development kit (SDK) toolkits such as the Android SDK and Apple Xcode. Worklight Studio enhances ease of development by supporting a browser simulator and integration with a native SDK toolkit.

In addition, Worklight Studio supports invocation of the SQLAdapter procedure (or other types of adapters) from the client's perspective (mimicking mobile device client-originated requests) or back-end service calls from the middleware's perspective (mimicking a Worklight Server-originated request) to receive data the service retrieves from the back end (SQL database server) for testing purposes. Figure 12 and Figure 13 show the Worklight Studio support for back-end service testing and service response validation, respectively.

Figure 12. Invoking a back-end service from Worklight Studio: request
Image showing the request when invoking a back-end service from Worklight Studio
Figure 13. Invoking a back-end service from Worklight Studio: response
Image showing the response when invoking a back-end service from Worklight Studio

Use the mobile browser testing simulator to test mobile Worklight applications targeted for Android, Apple iPhone, Blackberry devices, Windows Phone, and mobile web application platforms. This capability facilitates testing of mobile applications on a variety of available and supported mobile devices for page appearance in mobile device microbrowsers, screen resolutions, form factors, screen orientation, and so on. In addition, you can use this capability to validate functional testing of Cordova abstraction. Figure 14 shows the testing of an application in a mobile browser simulator.

Figure 14. Testing in a mobile browser simulator
Image showing testing in a mobile browser simulator

Use the Android Emulator to test and debug Worklight Studio-developed mobile applications targeted for Android devices. The Android Emulator is an implementation of the Android Dalvik virtual machine (VM) designed to run within an Android virtual device on the same computer that hosts Worklight Studio. The Android Emulator enables simulation of network connection speed and latency, external storage cards, and user and system events. Because the emulator is an actual implementation of Dalvik VM without being attached to any particular vendor hardware (Samsung, HTC, Sony, Huawei, and so on), emulator testing helps to validate mobile application logic in terms of baseline functionality, removing hardware-injected and vendor hardware-specific issues. Figure 15 and Figure 16 show mobile application testing using the Android API 8 emulator with request and response flows, respectively.

Figure 15. Testing in an Android emulator: request
Image showing testing of a request in an Android emulator
Figure 16. Testing in an Android emulator: response
Image showing the response in an Android emulator

Figure 17 provides a preview of a mobile web application running on Jetty server embedded in Worklight Studio. Because the tooling runtime environment (Jetty) does not understand the operational runtime environment specifics of WASLTPARealm associated with the WebSphere Application Server runtime, the preview testing validates the correct rendering of the mobile web application UI.

Figure 17. Use the Worklight Console to preview and test the mobile web application running on a test server
Image showing a preview of the mobile web application in the Worklight Console

Figure 18 shows deployment of SQLAdapter to an operational Worklight Server instance using the Worklight Console.

Figure 18. Deploying the adapter from the Worklight Console
Image showing how to deploy the adapter from the Worklight Console

Figure 19 shows deployment of the mobile application to an operational Worklight Server instance using the Worklight Console.

Figure 19. Deploying the mobile application from the Worklight Console
Image showing how to deploy the application from the Worklight Console

Figure 20 shows complete deployment of mobile application assets to an operational Worklight Server instance using the Worklight Console.

Figure 20. Complete deployment of mobile application assets
Image showing complete deployment of application assets

Figure 21 shows direct deployment of the mobile application to the Worklight Application Center from Worklight Studio.

Figure 21. Direct deployment of the application to the Worklight Application Center
Image showing direct deployment of the application to the Worklight Application Center

Figure 22 shows export of the signed Android mobile application to a file system in Android Packaging format (.apk).

Figure 22. Export of the signed Android application to a file system
Image showing export of the signed Android application to a file system

Figure 23 shows uploading of the signed Android mobile application from the file system to a Worklight Application Center instance.

Figure 23. Upload of the signed Android application to the Worklight Application Center
Image showing upload of the signed Android application to the Worklight Application Center

Figure 24 shows the completed upload of the Android mobile application into the Worklight Application Center.

Figure 24. Completed Android application upload
Image showing the completed Android application upload

Server-side infrastructure configuration (Base Profile)

Complete the following steps for FIPS 140-2, logging, tracing, and instrumentation in a Base Profile:

  1. Enable the platform for FIPS 140-2 enforcement by clicking Local Security Policy > Security Options > System cryptography: use FIPS compliant algorithms for encryption, hashing and signing > Enabled.

    Note:Figure 25 shows FIPS 140-2 local security policy configuration for Windows. For details, refer to Resources.

    Figure 25. Windows local security policy FIPS 140-2 configuration
    Image showing Windows local security policy FIPS 140-2 configuration
  2. Start a WebSphere Application Server Base Profile instance, then connect your browser Administrator Console to the server and enable FIPS 140-2 configuration:
    1. Click Security > SSL certificate and key management > Manage FIPS > Enabled FIPS 140-2.
    2. Enable logging and tracing as well as change log detail:
      BASE-WIN2K8X64SSLTrace.log
      *=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
    3. Specify Java Virtual Machine (JVM) tracing by clicking Application servers > MobileServer > Process definition > Java Virtual Machine > Generic JVM arguments > -Djavax.net.debug=true.
    4. Define a custom JVM property:
      javax.net.debug=ssl:record:plaintext:handshake:verbose:keygen:session:
         defaultctx:sslctx:sessioncache:keymanager:trustmanager
    5. Log out of the Administrator Console.
    6. Stop WebSphere Application Server.
  3. Edit the client SSL configuration file:
    1. Create a backup of C:\I\WAS\profiles\Mobile\properties\ssl.client.props, and move it to a safe place.
    2. Edit the C:\I\WAS\profiles\Mobile\properties\ssl.client.props file contents:
      • Set com.ibm.security.useFIPS=true.
      • Set com.ibm.ssl.protocol=TLS.
  4. Edit the server-side java.security configuration file:
    1. Create a backup of C:\I\WAS\java\jre\lib\security\java.security, and move it to a safe place.
    2. Modify the following code:
      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
  5. Perform Worklight Server customization for the Base Profile on the deployed file system, as shown in Figure 26.
    Figure 26. Worklight Server customization for a Base Profile
    Image showing Worklight Server customization for a Base Profile
  6. Restart WebSphere Application Server.

Server-side infrastructure configuration (Liberty Profile)

Complete the following steps for FIPS 140-2, logging, tracing, and instrumentation in a Liberty Profile:

  1. Customize the server.xml file by adding ssl, keystore, and logging stanzas. (See the working file in Download.)
  2. Create and stage the jvm.options and log4j.properties files to the appropriate file system location. (See the provided working files.)
  3. Expand the worklight.war file, customize it as necessary, and then re-create the archive file.

Figure 27 shows the Worklight Server customization for a Liberty Profile on the deployed file system.

Figure 27. Worklight Server customization for a Liberty Profile
Image showing Worklight Server customization for a Liberty Profile

Make sure you point the environment setting to use the IBM Java software development kit (JDK):

  1. Run <drive>:\<was-root>\bin\setupCmdLine.bat to set the environment.
  2. Run <drive>:\<worklightserver-root>\server\wlp\bin\server.bat start worklightServer to launch a Worklight Server instance.
  3. Run <drive>:\<worklightserver-root>\server\wlp\bin\server.bat stop worklightServer to stop the Worklight Server instance.

Figure 28 provides a preview test of the mobile web application in an operational instance of Worklight Server. Because the instance is deployed on either WebSphere Application Server Liberty or Base Profile configurations, WASLTPARealm is a valid configuration, enabling the mobile web application to work correctly.

Figure 28. Operational preview of the mobile app in the Worklight Console
Image showing an operational preview of the mobile app in the Worklight Console

Figure 29 shows the Worklight Application Center client application running on an Android tablet.

Figure 29. The mobile app download in the Worklight Application Center client on an Android tablet
Image showing the mobile app download in the Worklight Application Center client on an Android tablet

Figure 30 shows the Worklight Device Runtime Components with the Worklight mobile application configured to communicate with server-side components.

Figure 30. The mobile client configuration settings
Image showing the mobile client configuration settings

Figure 31 shows the mobile application deployed to and running on an Android tablet.

Figure 31. The mobile client running on an Android tablet
Image showing the mobile application running on an Android tablet

Figure 32 shows the server challenge window displayed on an Android tablet. The window shows capture of user credentials.

Figure 32. The server challenge window of the mobile app (Android tablet)
Image showing the server challenge window of the mobile application (Android)

Figure 33 shows successful execution of the mobile application, with a successful end-to-end request-response flow, given valid user and database credentials.

Figure 33. Successful mobile app execution with valid credentials
Image showing successful mobile app execution with valid credentials

Figure 34 shows unsuccessful execution of the mobile application, with an end-to-end request-response flow failing, given invalid user credentials.

Figure 34. Unsuccessful mobile app execution with invalid credentials
Image showing unsuccessful mobile app execution with invalid credentials

Verification and validation analysis

The complete SSL handshake taking place between the client and the server is shown between lines 513 and 1644 of the diagnostic logging, tracing, and instrumentation output file BHARSSLLibertyTrace.log. See Figure 35 and the related trace files available for download. The trace file contents highlighted are for one complete flow of a handshake. The log file shows multiple SSL handshakes. You can see the same pattern from the log file captured for the Base Profile.

Figure 35 shows the SSL-FIPS 140-2 handshake flow between the mobile client running on a mobile device and the server infrastructure running in an IBM Java environment.

Figure 35. SSL-FIPS 140-2 handshake verification and validation from logging, tracing, and instrumentation
Image showing the SSL-FIPS 140-2 handshake verification and validation from logging, tracing and instrumentation

Lines 513, 597, 664, 700, 1257, 1274, 1608, and 1644 show the flows depicted in Figure 35. The rest of analysis details are as follows:

  • Client hello. The client sends the server information, including the highest version of SSL it supports and a list of the cipher suites it supports. (TLS 1.0 is indicated as SSL 3.1.) The cipher suite information includes cryptographic algorithms and key sizes:

    [TLSv1]
    Cipher Suites: [SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, 
    SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, 
    SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, 
    SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, 
    SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, 
    SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, 
    SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, 
    SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 
    SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_RC4_128_SHA, 
    SSL_ECDHE_ECDSA_WITH_RC4_128_SHA, SSL_ECDH_RSA_WITH_RC4_128_SHA, 
    SSL_ECDH_ECDSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, 
    SSL_RSA_WITH_RC4_128_MD5, SSL_RENEGO_PROTECTION_REQUEST]
  • Server hello. The server chooses the highest version of SSL and the best cipher suite that both the client and server support and sends this information to the client:

    [TLSv1]
    Cipher suite:  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  • Certificate. The server sends the client a certificate or a certificate chain. A certificate chain typically begins with the server's public key certificate and ends with the certification authority's root certificate. This message is optional but is used whenever server authentication is required.

    chain [0] = [
    	[
    	  Version: V3
    	  Subject: CN=jserver, OU=SWG, O=IBM, C=US
    	  Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
    	
    	  Key:  IBMJCE RSA Public Key:
    	modulus:
    	92784621582682166728351409075866971283584823984202570663
    	   6691205183708192217704549284163862788883621027968419590
    	   1240083367311839739509555666734794620185285543768168406
    	   4656845523699425906713942512767748136348517281311271488
    	   022357661402480688236843830996347540486698724905002161
    	   313848064418923142829862028699247
    	public exponent:
    	65537
    	
    	  Validity: [From: Wed Jul 30 16:39:20 EDT 2003,
    	               To: Wed Oct 13 16:39:20 EDT 2021]
    	  Issuer: CN=jserver, OU=SWG, O=IBM, C=US
    	  SerialNumber: [1059597560]
    	
    	]
    	  Algorithm: [MD5withRSA]
    	  Signature:
    	0000: 10 f0 91 c0 45 01 c7 3e  be f4 0e 7f 02 83 c1 2e  ....E...........
    	0010: 26 08 9e ba 30 2d f6 3e  c3 7c 49 c8 30 a2 7b e1  ....0.....I.0...
    	0020: a7 78 b9 e2 ac bf b5 1d  74 41 6c d3 89 61 04 c2  .x......tAl..a..
    	0030: a7 33 74 d0 28 2a d8 cf  cb 53 ab 54 79 e6 50 de  .3t......S.Ty.P.
    	0040: 0c 22 76 2a 85 51 cb a5  8b 66 7e f3 07 7a d2 af  ..v..Q...f...z..
    	0050: 2f cb aa 9d 27 59 2f 83  d6 ad c0 c7 50 57 62 c5  .....Y......PWb.
    	0060: 7f b4 cf 35 c7 26 50 b0  fd fc b5 7d 87 70 15 a0  ...5..P......p..
    	0070: 16 ec 16 e9 19 02 ba 05  d1 9b ce fb fe 2f ac 89  ................
    	
    	]
  • Server key exchange. The server sends the client a server key exchange message when the public key information sent in step 3 is not sufficient for key exchange:

    *** Diffie-Hellman ServerKeyExchange
  • Server hello done. The server tells the client that it is finished with its initial negotiation messages:

    *** ServerHelloDone
  • Client key exchange. The client generates information used to create a key to use for symmetric encryption. For RSA encryption, the client then encrypts this key information with the server's public key and sends it to the server:

    *** ClientKeyExchange, DH
  • Finished. The client tells the server that it is ready for secure data communication to begin:

    *** Finished
  • Finished. The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.

    *** Finished

The communication between the Worklight Server instance hosting the Worklight SQLAdapter and the back-end DB2 database server can be seen in the same log file. Searching for the SQLQuery keyword in the log file results in the content shown in Figure 36. The log file confirms the flowing of the SQL call to the back end and the associated back-end response.

Figure 36. Back-end flow verification and validation from logging, tracing, and instrumentation Enlarge the figure
Image showing back-end flow verification and validation from logging, tracing, and instrumentation

Conclusion

Part 1 of this series on configuring Worklight Server for FIPS 140-2 compliance testing shows how to configure a server-side WebSphere Application Server infrastructure consisting of WebSphere Application Server with Liberty and Base Profiles, a DB2 server, and Worklight Server for FIPS 140-2 compliance validation and certification.

You learned how to install IBM Mobile Foundation, offering product prerequisites (Oracle JDK, Android SDK, DB2) and IBM Mobile Foundation products (Worklight Studio and Worklight Server on Liberty and Base profiles of WebSphere Application Server). You learned how to develop a simple mobile application using Worklight Studio, test the mobile application using multitude of approaches, deploy the mobile application to an operational environment and Worklight Application Center, configure the environment for FIPS 140-2 testing, test the application on mobile devices, and validate the end-to-end testing of the mobile application for compliance validation and certification using infrastructure logging, tracing, and instrumentation.

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_01172013.zip104MB

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


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Mobile weekly

    Innovations in tools and technologies for mobile development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Mobile development, WebSphere, Security, DevOps
ArticleID=931730
ArticleTitle=IBM Worklight server configuration for FIPS 140-2 validation and certification, Part 1: Configuring a server-side WebSphere Application Server infrastructure
publish-date=05282013