PODER EJECUTIVO
EL GOBIERNO DE LOS ESTADOS UNIDOS DE AMERICA I. GENERAL
Although you can choose which apps available through Worx Home, you may also want to define how those apps interact with XenMobile. If you want users to authenticate after a certain period of time has passed or you want them to be able to access their information while offline, you do so through app policies. The following list includes some of the policies and discusses how you might use them. For a list of all MDX policies per platform, see MDX Policies at a Glance.
App passcode
Why use this policy: When you enable the app passcode setting, Worx prompts a user to
authenticate to the managed app before they can open the app and access any data.
Authentication might consist of the users Active Directory password, their Worx PIN, or their iOS TouchID depending what you configure under Client Properties in your Server Settings. You can set an inactivity timer in Client Properties so that, with continued use, Worx doesn't prompt the user to authenticate into the managed app again until the timer expires.
The app passcode differs from a device passcode in that, with a device passcode policy pushed to a device, Worx prompts the user to configure a passcode or PIN, which they must unlock before they can gain access to their device when they turn on the device or when the inactivity timer expires. For more information, see Authentication in XenMobile.
User example: When opening the WorxWeb application on the device, the user is prompted to
enter their Worx PIN before they can browse web sites if the inactivity period is expired.
App update grace period (hours)
Why use this policy: This grace period is the time available to the user before they must update
an app that has a newer version released in the WorxStore. At the point of expiry, the user must update the app before they can gain access to the data in the app. When setting this value, keep in mind the needs of your mobile workforce, particularly those who might experience long periods off line when travelling internationally.
User example: An administrator has loaded a new version of WorxMail in the WorxStore that has
some new features and improvements that users need to do their job. The administrator sets an App update grace period of 6 hours. All WorxMail users will see a message asking them to update their WorxMail app until the 6 hours expires. When the 6 hours expires, the user is automatically routed to the WorxStore.
Active poll period (minutes)
Why use this policy: The Active poll period is the interval at which the XenMobile Server will
check apps for when to perform security actions to the Worx container, such as App Lock and App Wipe.
User example: If you set this Active poll period to 60 minutes, when you send the App Lock
command from the XenMobile Server to the device, the lock occurs within 60 minutes of when the last poll took place.
Encryption
Why use these policies: XenMobile includes a secret vault with a strong encryption layer that
Worx Home and other Worx apps use to persist their sensitive data, such as passwords and encryption keys on the device without depending on the platform native keystores. This means that if the device is compromised in any way, corporate data remains encrypted in the MDX container and is obfuscated when transferred outside of the container.
User example: If the device owner did not set a device PIN or the device PIN is compromised,
the corporate data inside the Worx container remains secure.
App geofence policies
Why use these policies: The policies that control app geofencing are under the heading General
Policies and include Center point longitude, Center point latitude, and Radius. Those policies contain access to the data in the MDX apps to a specific geographical area. The area is defined by a radius of latitude and longitude coordinates. If a user attempts to use an app outside of the defined radius, the app remains locked and the user cannot access the app data.
User example: A user has access to merger and acquisition data while they are in their office
location. When they move outside of their office location, this sensitive data becomes inaccessible.
WorxMail Background network services
Why use this policy: Background network services in WorxMail leverages Secure Ticket
Authority (STA), which is effectively a SOCKS5 proxy to connect through NetScaler Gateway. STA supports long-lived connections and provides better battery life compared to micro VPN, and so STA is ideal for mail that connects constantly. Citrix recommends that you configure these settings for WorxMail. The NetScaler for XenMobile wizard automatically sets up STA for WorxMail.
User example: When an Android user opens WorxMail and STA is not enabled, they are
prompted to open a VPN, which remains open on the device. If the Android user opens WorxMail and STA is enabled, WorxMail opens and connects seamlessly with no VPN required.
WorxMail Default sync interval
Why use this policy: This setting specifies the default days of email that will be synchronized to
WorxMail when the user accesses WorxMail for the first time. Be aware that 2 weeks of email takes longer to sync than 3 days and prolongs the setup process for the user.
User example: If the default sync interval is set to 3 days when the user first sets up WorxMail,
they can see any emails in their Inbox that they received from the present to 3 days in the past. If a user wants to see emails that are older than 3 days, they can do a search and WorxMail will show the older emails stored on the server. Each user can change this setting after WorxMail has been set up to better suit their needs.
XenMobile Deployment Handbook
© 2016 Citrix Systems, Inc. All rights reserved 105