Android - Security Module Interface

The SecurityModule interface allows you to implement custom security checks at critical points within your application. These security checkpoints act as gatekeepers for sensitive operations and user flows. You have complete control over what security validations are performed and how they're implemented. When any security check returns a Deny result, the associated flow is immediately canceled or blocked, protecting your application from potential security threats.

Implementation

Create a class that implements the SecurityModule interface. Once implemented, override the provided methods and add your custom security logic as required.

/**
 * Example SecurityModule implementation.
 *
 * A SecurityModule hooks into critical security checkpoints within the application.
 * Through this interface, you can implement custom security validations such as device
 * integrity checks, authentication requirements, and access control policies.
 */
class SecurityModuleExample(private val sdkUtils: SdkUtils): SecurityModule {

    override fun isDeviceSecure(): SecurityResult {
        // Implement your device security checks here
        // Examples: root detection, screen lock validation, etc.
    }

    override fun allowLogin(): SecurityResult {
        // Implement your login authorization checks here
        // Examples: time-based restrictions, location validation, etc.
    }
}

/**
 * Security Result Types
 *
 * Return values for SecurityModule interface methods. Use these predefined
 * result types to indicate the outcome of security checks.
 *
 * - Allow: Device passes all security checks and the flow can continue
 * - Deny: Security violation detected with a descriptive message explaining the issue
 */
sealed class SecurityResult {
    object Allow : SecurityResult()
    data class Deny(val message: String) : SecurityResult()
}

SecurityResult Breaking Change in Version 25.11.0

The SecurityModule interface was first introduced in version 25.9.0 using SecurityResult.Secure and SecurityResult.Insecure(message) as return values. In version 25.11.0, these were renamed to SecurityResult.Allow and SecurityResult.Deny(message) respectively for better clarity and consistency.

If you're upgrading from version 25.9.0, you'll need to update your SecurityResult return values:

• Change SecurityResult.Secure to SecurityResult.Allow
• Change SecurityResult.Insecure(message) to SecurityResult.Deny(message)

The functionality remains identical - only the naming has changed.

Security Methods

isDeviceSecure()

This method is called before sensitive operations to validate the overall security posture of the device. Common implementations include checking for device rooting, verifying screen locks are enabled, or validating device encryption status.

allowLogin()

This method is invoked during the authentication process to determine if login should be permitted under current conditions. Typical use cases include enforcing time-based access restrictions, validating user location, or checking network security requirements.

Testing with Native Login

To test the allowLogin() method in your development environment, you need to enable the Native Login module in your settings.json. The legacy login page does not trigger this security checkpoint. Learn how to enable Native Login in Native Login Module.

Update Your settings.json

Ensure your settings.json file in the root of the DevApp is updated to reflect your module changes. Learn more in Configuring settings.json.