Various scenarios prompt users to authenticate with XenMobile by entering their credentials on their devices.
The scenarios change depending on these factors:
In addition, the kind of credentials that users enter—Active Directory password, Worx PIN or passcode, or Touch ID—also change based on the type of authentication and frequency of authentication that you require.
Let's start with the scenarios that result in an authentication prompt.
Offline inactivity (time-out). With the App Passcode MDX policy enabled, which it is by default, the XenMobile client property called Inactivity Timer comes into play. The Inactivity Timer limits the length of time that can pass without user activity in any of the apps that use the secure container.
When the Inactivity Timer expires, users must reauthenticate to the secure container on the device. If, for example, users set down their devices and walk away, if the Inactivity Timer has expired, someone else can't pick up the device and access sensitive data within the container. You set the Inactivity Timer client property in the XenMobile console. The default is 15 minutes. The combination of the App Passcode set to ON and the Inactivity Timer client property is responsible for probably the most common of the authentication prompt scenarios.
Signing off from Worx Home. When users sign off from Worx Home, they have to reauthenticate the next time they access Worx Home or any MDX app, when the app requires a passcode as determined by the App Passcode MDX policy and the Inactivity Timer status.
Maximum offline period. This scenario is specific to individual apps because it is driven by a per-app MDX policy. The Maximum offline period MDX policy has a default setting of 3 days. If the time period for an app to run without online authentication with Worx Home elapses, a check-in with XenMobile server is required in order to confirm app entitlement and to refresh policies. When this check-in occurs, the app triggers Worx Home for an online authentication. Users must reauthenticate before they can access the MDX app.
Note the relationship between the Maximum offline period and the Active poll period MDX policy:
Both check-ins with the XenMobile server, for Active poll period and Maximum offline period expiry, require a valid NetScaler Gateway token on the device. If the device has a valid NetScaler Gateway token, the app retrieves new policies from XenMobile without any interruption to users. If the app needs a NetScaler Gateway token, a flip to Worx Home occurs, and users see an authentication prompt in Worx Home.
On Android devices, the Worx Home activity screens open directly on top of the current app screen. On iOS devices, however, Worx Home must come to the foreground, which temporarily displaces the current app.
After users enter their credentials, Worx Home flips back to the original app. If, in this case, you allow for cached Active Directory credentials or you have a client certificate configured, users can enter a Worx PIN or password, or their Touch ID (iOS). If you do not, users must enter their complete Active Directory credentials.
The NetScaler token may become invalid due to NetScaler Gateway session inactivity or a forced session time-out policy, as discussed in the following list of NetScaler Gateway policies. When users sign on to Worx Home again, they can continue running the app.
NetScaler Gateway session policies. Two NetScaler Gateway policies also affect when users are prompted to authenticate. In these cases, they authenticate in order to create an online session with NetScaler for connecting to XenMobile server.
The preceding section discussed when users are prompted to authenticate. Let's now discuss the kinds of credentials they must enter. Authentication is necessary through various authentication methods in order to gain access to encrypted data on the device. To initially unlock the device, you unlock the primary container. After this occurs and the container is secured again, to gain access again, you unlock a secondary container.
Note: When the article refers to a managed app, the term refers to an app wrapped by the MDX Toolkit, in which you've left the App Passcode MDX policy enabled by default and are leveraging the Inactivity Timer client property.
The circumstances that determine the credential types are as follows:
Active Directory credentials are required for either container unlock circumstance when the following conditions are true:
The following flowchart summarizes the decision flow that determines which credentials a user must enter when prompted to authenticate.
Another situation to note is when a flip from an app to Worx Home and then back to an app is required. The flip displays a notification that users must acknowledge. Authentication is not required when this occurs. The situation occurs after a check-in happens with XenMobile server, as specified by the Maximum offline period and Active poll period MDX policies, and XenMobile detects updated policies that need to be pushed to the device through Worx Home.