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.
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.
Liberty Profile v220.127.116.11, 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
WebSphere Application Server Base Profile v18.104.22.168, 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
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
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
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
When the user clicks Call protected DB2 SQL adapter
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
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
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
Figure 7 shows the populated USECASES table, which consists of nine rows.
Figure 7. USECASES table data
As part of 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
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
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
AuthBody identifiers. This source file also
file defines functions named
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
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-securityTestis a security test that was created to define security configurations to protect Worklight application resources, such as an adapter procedure named
Realm = "WASLTPARealm".
WASLTPARealmis an authentication realm that protects resources, such as an adapter procedure named
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.FormBasedAuthenticatorpresents 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.NonValidatingLoginModuleaccepts any user name-password combination.
com.worklight.core.auth.ext.SingleIdentityLoginModulegrants 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
Figure 8. Authenticated downstream flow: 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
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
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
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
Figure 13. Invoking a back-end service from Worklight Studio: response
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
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
Figure 16. Testing in an Android emulator: response
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
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
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
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
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
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
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
Figure 24 shows the completed upload of the Android mobile application into the Worklight Application Center.
Figure 24. Completed Android application upload
Complete the following steps for FIPS 140-2, logging, tracing, and instrumentation in a Base Profile:
- 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.
Figure 25. Windows local security policy FIPS 140-2 configuration
- Start a WebSphere Application Server Base Profile instance, then
connect your browser Administrator Console to the server and enable
FIPS 140-2 configuration:
- Click Security > SSL certificate and key management > Manage FIPS > Enabled FIPS 140-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
- Specify Java Virtual Machine (JVM) tracing by clicking Application servers > MobileServer > Process definition > Java Virtual Machine > Generic JVM arguments > -Djavax.net.debug=true.
- Define a custom JVM property:
- Log out of the Administrator Console.
- Stop WebSphere Application Server.
- Edit the client SSL configuration file:
- Create a backup of C:\I\WAS\profiles\Mobile\properties\ssl.client.props, and move it to a safe place.
- Edit the C:\I\WAS\profiles\Mobile\properties\ssl.client.props
- Edit the server-side java.security configuration file:
- Create a backup of C:\I\WAS\java\jre\lib\security\java.security, and move it to a safe place.
- 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
- 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
- Restart WebSphere Application Server.
Complete the following steps for FIPS 140-2, logging, tracing, and instrumentation in a Liberty Profile:
- Customize the server.xml file by adding
loggingstanzas. (See the working file in Download.)
- Create and stage the jvm.options and log4j.properties files to the appropriate file system location. (See the provided working files.)
- 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
Make sure you point the environment setting to use the IBM Java software development kit (JDK):
<drive>:\<was-root>\bin\setupCmdLine.batto set the environment.
<drive>:\<worklightserver-root>\server\wlp\bin\server.bat start worklightServerto launch a Worklight Server instance.
<drive>:\<worklightserver-root>\server\wlp\bin\server.bat stop worklightServerto 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,
a valid configuration, enabling the mobile web application to work
Figure 28. 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
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
Figure 31 shows the mobile application deployed to and running on an Android tablet.
Figure 31. The mobile client 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)
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
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
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
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  = [ [ Version: V3 Subject: CN=jserver, OU=SWG, O=IBM, C=US Signature Algorithm: MD5withRSA, OID = 1.2.840.113522.214.171.124 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:  ] 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:
- 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. The server tells the client that it is
ready for secure data communication to begin. This is the end of the
The communication between the Worklight Server instance hosting the
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
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.
The author gratefully acknowledges the feedback, constructive suggestions, support, and productive teaming from the following IBMers:
- William D. Dodd, Software Engineer, Mobile Application Platform (firstname.lastname@example.org)
- William J. O'Donnell, WebSphere Foundation Security Architect (Bill.ODonnell@us.ibm.com)
- Ian Robinson, Distinguished Engineer, WebSphere Foundation Chief Architect (email@example.com)
- Srinivas R. Sama, Software Engineer, IBM Worklight Support (firstname.lastname@example.org)
- Tom A. Dressel, Software Engineer, IBM Mobile Foundation/Worklight Support (email@example.com)
- Raj Balasubramanian, Senior Software Engineer, Product Architect for IBM Mobility Services (firstname.lastname@example.org)
- Parviz Behseta, IT Architect, IBM Sales and Distribution (email@example.com)
- Mark A. Smith, WebSphere Technical Professional Manager (firstname.lastname@example.org)
|Application sample, configuration, and log files||articlebundle_01172013.zip||104MB||HTTP|
- Learn to configure the Windows platform
for FIPS 140-2 at "System
cryptography: Use FIPS compliant algorithms for encryption, hashing,
and signing" security setting effects in Windows XP and in later
versions of Windows.
- Learn about FIPS 140-2 at the NIST Computer
Security Resource Center.
- Learn about Transport Layer Security
(TLS) at the Internet
Engineering Task Force (IETF) TLS Workshop.
- Learn about SSL Protocol version 3.0 at
SSLv3.0 IETF Request for
- Visit the WebSphere Application Server Information Center.
- Learn more about IBM Worklight
V5.0.6 at IBM
Worklight V5.0.6 Information Center.
- Learn more about the Abstract
Class ChallengeHandler Documentation in section 2.3 of the IBM Worklight V5.0.6
Java client-side API for native Android
- Learn how to run IBMJSSE2 in FIPS mode.
- Learn how to enable FIPS Mode in the IBMJSSE2 Provider.
- Learn programming practices at the Java FIPS-approved providers, IBMJSSEFIPS and
- Learn how to configure Federal Information Processing Standard Java Secure Socket
- Review the Getting started with IBM Worklight modules
on authentication and security.
- In the developerWorks Mobile development
site, access and learn how to use the latest tools and technologies
for mobile application developers in the comprehensive IBM MobileFirst product portfolio.
Explore our free software downloads and cloud trials, sample code,
expert how-to advice, videos, training, and discussion—all focused
on helping you develop, test, integrate, analyze, secure, and
manage multi-platform mobile applications and deployments in your
Get products and technologies
- Download or
purchase the IBM
Worklight mobile application platform.
- Download or
purchase the WebSphere Application Server.
IBM products in the way that suits you best: Download a product
trial, try a product online, use a product in a cloud environment, or
spend a few hours in the SOA Sandbox learning how to implement
service-oriented architecture efficiently.
- Learn more about the WebSphere
Application Server Liberty Profile at
Check out developerWorks
blogs and get involved in the developerWorks
Bhargav 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.