000031833 - How to do mobile device application development for RSA Adaptive Authentication (on Prem) without using the official RSA Mobile SDK

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000031833
Applies ToRSA Product Set: Adaptive Authentication (OnPrem)
RSA Product/Service Type: Mobile SDK
RSA Version/Condition: 7.x
IssueSometimes due to internal requirements, or because a device is not supported by our SDK, users want to know if they can create a mobile application but not use the RSA Mobile SDK.  With the exception of the new biometric features, they can just gather the info on their own and create the JSON string described in the SDK documentation.
Tasks

Request and download the latest RSA Mobile SDK for its documentation. A JSON string will need to be created manually in your application following the structure defined in the documentation.
It is especially important to make sure a unique identifier is included in one of the elements: simID, hardwareID, phoneNumber or otherID. Since these values are used by the risk engine it is best to fill in as many as you can and not just populate all with the same value. 
The device token generated in AAOP can also be stored in the mobile application and passed back to AAOP, as it would in a web application using cookies.

Notes

The risk engine actually looks over all the device ID values and changes to any that affect the risk score.  Using the same value in all identifiers is not recommended since none of them on their own are a foolproof device identifier. Android ID is easily changed so using that as the only identifier with device-based policy rules is not a secure solution. Android ID is also identical across all devices for certain device manufacturers. Best practice is to use multiple device identifiers and after sufficient learning period use risk based rules to challenge the riskier transactions. Note that if you change the source of values for simID, hardwareID and otherID (along with associated phone number), the risk model needs to go through a learning period before the scores will settle down. So, these type of changes can increase the challenge rate.
 
Avoiding the user approval to access simID and hardwareID is not recommended. The values are optional since they are not always available and to allow for less secure transactions who want to rely on device recovery alone.
Additional References:


Attachments

    Outcomes