Secure the MobileFirst Server administration

The security threat is that any person who can install mobile applications in a production environment is able to modify the behavior of these apps on the mobile devices. The apps are served to the clients through the MobileFirst runtime environments, which get these apps from the administration services through JMX. The administration services fetch these apps from the administration database. The administration services and the MPF operations console allow any user in the roles...

• worklightadmin
• worklightdeployer

...to deploy applications. A similar threat exists for adapters.

Enable https in the application server

The ability to use https with the application server is a prerequisite.

For WAS Liberty profile:

• Verify that the server.xml file contains either/both...
  • <feature>ssl-1.0</feature>
  • <feature>restConnector-1.0</feature>.

  The restConnector-1.0 feature implies that the ssl-1.0 feature is enabled.

• Verify that the HTTPS port is enabled, by ensuring that the server.xml file does not have an <httpEndpoint> element with a httpsPort attribute that is negative.

  If the HTTPS port is disabled, SSL is also disabled, and the JMX connections that the MobileFirst Server requires do not work.

• Verify that the server.xml file contains...
  <keyStore id="defaultKeyStore" .../>

  ...or an equivalent declaration, otherwise the JMX connections that the MobileFirst Server requires do not work.

For Apache Tomcat:

• Enable an https port as documented in SSL support and SSL Configuration HOW-TO.

Enable application security in the application server

Without this step, anyone can connect to the web applications without credentials.

For WAS full profile:

• Verify that Administrative Security is enabled.

• Verify that Application Security is enabled.

For WAS Liberty profile:

• Verify that the server.xml file contains <feature>appSecurity-1.0</feature>.

Protecting the passwords of users in the roles worklightadmin and worklightdeployer

If the password of any user who is mapped to the roles worklightadmin or worklightdeployer is compromised, that is, becomes potentially known to an unauthorized person, unauthorized MobileFirst administration operations are possible. Here are steps to mitigate this risk.

• Minimize the number of users that you map to the roles worklightadmin and worklightdeployer.

• Map different users to the roles worklightadmin or worklightdeployer in development and test environments than you do in the production environment. If the password of the administrator of the development or test environment is compromised (for example, by use of secure="false"), this helps secure the password of the administrator of the production environment.

• If these users are authenticated through LDAP, secure the connection to the LDAP server.

• Never use the operations console or the MobileFirst Administration REST services over http. Always use https. There are two ways to guarantee this:

  • Configure the application server to respond only to an https port, not to an http port.

  • Modify the worklightconsole.war and worklightadmin.war files to activate the JEE6 transport security of type CONFIDENTIAL. This setting performs a redirect from http to https before the application server requests a user and password.

    1. Unpack worklightconsole.war (as a .zip file).

    2. Edit its WEB-INF/web.xml file, changing <transport-guarantee>NONE</transport-guarantee> to <transport-guarantee>CONFIDENTIAL</transport-guarantee>.

    3. Repack worklightconsole.war.

    4. Unpack worklightadmin.war (as a .zip file).

    5. Edit its WEB-INF/web.xml file, changing <transport-guarantee>NONE</transport-guarantee> to <transport-guarantee>CONFIDENTIAL</transport-guarantee>.

    6. Repack worklightadmin.war.

    7. Redeploy these WAR files, either manually, or through the Ant task <installworklightadmin> or <updateworklightadmin>. See Deploy the operations console and administration services with Ant tasks.

• Never use the <wladm> Ant task with the attribute secure="false", and never use the wladm command with the option -secure=false. To achieve this, we must:

  • Ensure that the application server uses an SSL certificate signed by a CA, not a self-signed certificate, and that the host name mentioned in this certificate matches the host name of the application server machine.

  • Ensure that this SSL certificate is contained in the truststore of the JVM that runs the <wladm> Ant task or the wladm command.

• Change the file access permissions of the file containing the password used by the <wladm> Ant task or the wladm command to be as restrictive as possible. To do this, we can use a command, such as the following examples:

  • On UNIX: chmod 600 adminpassword.txt

  • On Windows: cacls adminpassword.txt /P Administrators:F %USERDOMAIN%\%USERNAME%:F

• Additionally, you might want to obfuscate the password, to hide it from an occasional glimpse. To do so, use the wladm config password command to store the obfuscated password in a configuration file. Then we can copy and paste the obfuscated password to the Ant script or to the password file you want.

• In the configuration of the operations console web application, set the JNDI property ibm.worklight.admin.ui.cors.strictssl to true. This property helps rejecting unsecure SSL certificates.

• In the configuration of the operations console web application, set the JNDI property ibm.worklight.admin.hsts to true. This property implements HTTP Strict Transport Security and helps the administrator's browser remember to access the operations console through https instead of http.

Protecting the administration database

If the password of the administration database (or of the user who owns the corresponding schema of that database) is compromised, that is, becomes potentially known to an unauthorized person, unauthorized deployments of apps and adapters are possible. Here are steps to mitigate this risk.

• Do not host other services than the database management system on the machines that serve this database.

• If we use Ant tasks to configure the MobileFirst Server administration (see Use Ant tasks to install MobileFirst Server administration), we must do one of the following actions:

  • Change the file access rights of the Ant XML file to be as restrictive as possible before you store passwords in it. See step 2 in Sample configuration files.

  • Write ************ (12 asterisks) in place of the password, so the Ant XML file does not contain the password. Instead, the Ant task queries the password interactively when it is invoked.

• Minimize the number of users who have login access to the machines that run MobileFirst Server.

• Change the file access rights of the application server configuration files containing the jdbc/WorklightAdminDS data source password to be as restrictive as possible. See step 3 in Sample configuration files.

Protecting the JMX communication

If the JMX communication between administration services and the MobileFirst runtime environments are not secured, unauthorized persons who have local access to the MobileFirst Server machines can play man-in-the-middle attacks and thus activate tampered apps and adapters. Here are steps to mitigate this risk.

• For WAS Liberty, follow the procedure of Configure secure JMX connection to the Liberty profile.

• For Apache Tomcat, use a JMX configuration with SSL, as described in Configure Apache Tomcat.

Protecting the apps and adapters to deploy

If the source from which the MobileFirst administrator receives apps and adapters is not secured, tampered apps and adapters can be submitted to the MobileFirst administrator, who then deploys them. Here are steps to mitigate this risk.

• Ensure that the MobileFirst administrator receives apps and adapters only through channels which guarantee the integrity of the sender and of the sent artifacts. For example, use emails with digital signature, or web-based tools with the need to log in through https.

• Ensure that the development teams that create these apps and adapters use a Version Control System that guarantees the integrity of each modification and disallows modifications by unauthorized persons. Examples of VCS systems in this category are RTC/jazz and Git. An example of a VCS not in this category is CVS.

Protecting against attacks from the internet

Attackers from the internet might attempt to search for security flaws in the operations console and administration services and try to circumvent the security measures. Here is a tip to mitigate this risk. It assumes that mobile application users connect to MobileFirst Server from the internet, but all legitimate uses of the operations console Console and administration services are from an intranet.

• Configure the internet gateway or firewall (for example, IBM DataPower) to block access to URLs under the context roots of the operations console (default: /worklightconsole) and of the administration services (default: /worklightadmin). At the same time, keep the access to the MobileFirst runtime web applications open.

Parent topic: Security configuration