Configuring extended app authenticity checking

Checking extended application authenticity is an additional method of verifying that the MobileFirst application on the device has not been tampered with.

Enabling extended authenticity checking

Extended application authenticity checking is supported for the following environments:
  • iPhone, iPad, and iOS native
  • Android and Android native
  • Windows Phone Silverlight 8 (but not Windows Phone Silverlight 8 native)
  • Windows 8 Universal (including Windows Phone 8 Universal), Windows 8 Universal native , and Windows Phone 8 Universal native
Note:
  • You cannot enable extended authenticity if you use the internal MobileFirst Development Server that is embedded in MobileFirst Studio.
  • Extended application-authenticity validation is not supported for iOS apps that are installed from the Apple app store. See the Extended application authenticity for iOS known limitation.
  • If your Android app uses extended authenticity, it cannot use the multiple APK feature of Google Play. See Multiple APK Support for more information about the multiple APK feature.
To enable extended authenticity checking, you must deploy a modified .wlapp file, instead of the original .wlapp file that is generated by the build process. To obtain the modified .wlapp file, use one of the following two facilities:
  • The enable-extended-authenticity command of the wladm Ant task, as described in Commands for apps.
  • The enable extended-authenticity command of the wladm program, as described in Commands for apps.
You need to specify the following files as inputs for those commands:
  • The .wlapp file, from the bin folder of your MobileFirst project.
  • The mobile application file for the device, that is:
    • For the iPhone, iPad, iOS native environments: the corresponding .ipa file. If your application must support both 32-bit and 64-bit execution, provide a single .ipa file that includes both 32-bit and 64-bit code.
    • For the Android and Android native environments: the corresponding .apk file.
      Note: The .apk file must be signed. For more information, see Signing Your Applications.
    • For the Windows Phone Silverlight 8 environment: the corresponding .xap file. If you build your application for ARM and x86 architectures, the .xap file to use for production deployment is the one for the ARM architecture; the .xap file for the x86 architecture is for use in emulators only.
      Note: If an application is built in Release mode and runs on a physical device, the .xap file of the application must be signed with a certificate to be able to connect to the MobileFirst Server. The resulting .xap file must be provided as the input to the wladm tool after the binaries are signed. For more information about signing enterprise apps, see Preparing company apps for distribution for Windows Phone.
    • For the Windows 8 Universal (including Windows Phone 8 Universal), Windows 8 Universal native, and Windows Phone 8 Universal native environments: the corresponding .appx file or the .appx file from a bundle.
The resulting, modified .wlapp file is the file that you deploy to the MobileFirst Server.
Note:
  • The extended application authenticity mechanism demands that there is a dedicated version of the .wlapp file per each version of the native app. Before you distribute a new version of the mobile application file (.ipa, .apk, .appx, or .xap), you must perform the following actions:
    1. Update the application version number in the application-descriptor.xml file.
    2. Rebuild to create a new .wlapp file.
    3. Run one of the commands described previously to enable authenticity checking on the production-ready .ipa, .apk, .appx, or .xap file and the new .wlapp file.
    4. Deploy the .wlapp file produced in step 3 to the MobileFirst Server.

Disabling extended authenticity checking

To revert from extended authenticity checking to basic authenticity checking, deploy the original .wlapp file to the MobileFirst Server, for each of the wanted environments.

Enabling extended authenticity checking for apps that undergo app thinning

App thinning was introduced by Apple in iOS 9 for apps that are compiled with Xcode 7. App thinning reduces the size of files that are downloaded from the App Store. The feature might affect the extended authenticity features of IBM MobileFirst™ Platform Foundation apps because the binary file in the App Store might differ from the one that is downloaded to the client device.

Starting with the latest interim fix of IBM MobileFirst Platform Foundation V7.1.0, the new ipa file that you upload to the App Store can take advantage of app thinning, without influencing extended authenticity. To enable this capability, you must perform the following actions:

  1. Configure the original .wlapp file by using the enable-extended-authenticity command of the wladm program, as described earlier in this page.
  2. Deploy the .wlapp file to the server for testing.
Note: App thinning does not take place in apps that were developed using earlier versions of iOS and Xcode.
Parent topic: Configuration of MobileFirst applications on the server