Application Authenticity Protection
This tutorial covers the following topics:
By issuing an HTTP request, any entity can access the HTTP services (APIs) that IBM MobileFirst Platform Foundation Server offers. As described in previous tutorials, it is possible to protect relevant services with various security tests.
The application authenticity check ensures that the application that tries to connect to a MobileFirst Server instance is the authentic one and was not tampered with or modified by a third-party attacker.
Application authenticity protection is available for:
- Android - native + hybrid
- iOS - native + hybrid
- Windows Phone 8 - hybrid only
Three levels of authenticity are available:
- No Authenticity
- Basic Authenticity
- Extended Authenticity (Provides a more detailed verification and is more secured.)
- Application authenticity protection is not available in the MobileFirst Development Server. To test, deploy the application to a MobileFirst Server instance on a remote application server.
- Application authenticity protection is available only to licensed installations of MobileFirst Server.
To set up application authenticity protection, you go through the following 2 steps:
Authenticity protection check flow
The challenge token is processed by compiled native code, so that third-party attackers cannot see the logic of this processing.
Application authentication is based on certificate keys that are used to sign application bundles.
Only the developers or the enterprise who have the original private key that was used to create the application are able to modify, repackage, and re-sign the bundle.
Enabling application authenticity protection
Whether you want Basic or Extended authenticity protection, the following setup steps are required.
Extended authenticity protection requires additional steps, as explained in the Enabling extended protection section.
authenticationConfig.xml configuration file
- Add the relevant authentication realm to a security test.
- If a
mobileSecurityTestis used, add the
testAppAuthenticitychild element to it:
- If a
customSecurityTestis used, add the
wl_authenticityRealmrealm to it:
- If a
- After you have configured the authenticity realm and security check, go to Environment-specific setup and select your environment to complete the authenticity configuration.
Enabling extended application authenticity protection
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.
- Modify the
.wlappfile by using the
wladmprogram or the
- By using the
wladmprogram (provided in the MobileFirst installation directory) to run the
src-wlapp-file => Original binary app file (.wlapp)
device-file => Binary mobile app file (.apk, .ipa, or .xap)
dest-wlapp-file => Output binary app file (.wlapp)
After running the
wladm, deploy the output file to MobileFirst Server instance.
- By using the
wladmAnt task (provided in the MobileFirst installation directory) to run the
wladmcommand or Ant task, deploy the output file to MobileFirst Server instance.
For more information, see the topic about configuring extended app authenticity checking in the user documentation.
Check the application authenticity level by using the MobileFirst Operations Console
You can use the MobileFirst Operations Console to see the authenticity level of an application.
Check authenticity level through MobileFirst Console[/caption]
For basic authenticity, the following steps are required.
For extended authenticity, it is recommended to make these extra configuration changes.
- Authenticity Protection in Hybrid applications
- Authenticity in Native Android applications
- Authenticity in Native iOS applications