0

During App Authenticity testing in MobileFirst 8.0, I found a strange behavior in switching between enable and disable of App Authenticity setting on Console, using an (Android) app's debug package and release package:

  • Followed the instruction of signing the app (release package) with mfp-app-authenticity-tool.jar tool, registered .authenticity_data file via Console, and set Security-Check Configurations of the app to use appAuthenticity setting with Expiration Period value.

  • (For initial connection) After installing the release version of the app on a device, the app successfully connects to MFF Server and calls an adapter.

  • (After removing the release version of the app from the same device) Installed debug version of the app on the device, and the app fails to connect to MFF Server, as expected.

  • Disabled App Authenticity by deleting Authenticity File on Console, the debug version of the app on the device successfully connects to MFF Server and calls an adapter.

  • "Re-enabled" App Authenticity with same instructions as the first step, but the debug version of the app still can connect to MFF Server and calls an adapter. I understand that there's Maximum Token-Expiration Period and Expiration Period setting, but I set both value to 60 seconds for just testing. (Reinstalling the debug version of the app and testing the action without changing on Server gives an expected behavior - i.e. not able to connect.)

I'm wondering if this is normal behavior of enabling / disabling App Authenticity setting in real-time on Console.. and if the feature is designed for just one set of actions of Enable -> Disable only.

Any thought?

Thanks!

Rick Choi
  • 29
  • 6
  • Where in the question is the part where it doesn't work? – Idan Adar Oct 24 '16 at 03:15
  • In bullet #5 (the last one), switching back from Disable to Enable doesn't work - i.e. debug version can still connect to Server. – Rick Choi Oct 24 '16 at 03:51
  • Why should it not be able to connect? – Idan Adar Oct 24 '16 at 07:01
  • Do you mean that you registered the debug apk, but signed and uploaded the authenticity file of the release apk? Are you sure there is a difference between those two? are you sure they are not generated with the same key in the ADT tools? Sounds like they are the same app – Idan Adar Oct 24 '16 at 08:24
  • When registering an app to the server, I believe that app name, platform (Android), bundle ID, and version info are required - i.e. not signed or debug. **Release version of apk should be treated as a totally different app from debug version of apk, as (simply and basically) the size of those apps are different.. No?** As mentioned in my questions, actions and (expected) results should be fine, from bullet # 1 to 4, but the problem - i.e. debug apk can connect to server, which is not supposed to happens like bullet # 3 - on "re-enabling" authenticity check. – Rick Choi Oct 24 '16 at 10:47
  • I registed an app with app info mentioned above, uploaded authenticity file generated with release version of the app, accesing server with the release version of the app is ok, accessing server with debug app fails to connect, disabling authenticity in Console, the debug apk connect to server, re-enabling authenticity with the same authenticity file used before, **debug apk still can connect to server** (even after token expiration). – Rick Choi Oct 24 '16 at 11:41

1 Answers1

1

By default, App Authenticity is only being checked during the client registration process. Which means that the next time you connect to the server, it will not be checked.

In order to run App Authenticity on every token request, add appAuthenticity to the Mandatory scope section on your application in the console. Then set the expirationSec to 60 seconds for example.

The tutorial was adjusted to clarify this: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/application-authenticity/#configuring-application-authenticity

Nathan H
  • 48,033
  • 60
  • 165
  • 247
  • Just tested the combined setting of Mandatory Application Scope and Security-Check Configurations as you suggested, and yes, it seems to work! Thanks a lot, @Nathan ! I set expiration period with 5 seconds, just for testing, and would it be too much load for MFF Server..? and I believe that being able to customizing "Error" message should be highly wanted feature, as proposed here: http://stackoverflow.com/questions/38650913/mobilefirst-8-0-app-authenticity-custom-message – Rick Choi Oct 25 '16 at 17:43
  • I don't think the performance hit is that big. But maybe 5 seconds is overkill. Keep in mind, OAuth token expiration is set to whatever the shortest expiration you have among all your security checks. So if one of them is 5 seconds, it means the entire OAuth token will expire every 5 seconds. – Nathan H Oct 26 '16 at 05:47
  • I will keep in mind the fact that other OAuth token based security related parameters specific to expiration value precedes the general token expiration value setting. Thanks @Nathan. – Rick Choi Oct 26 '16 at 22:35