• No results found

Locking and Unlocking Application Connections

Lock or unlock connections to control which users are allowed to synchronize data. Locking an application connection is an effective way to disable a specific user without making changes to the security profile configuration to which he or she belongs. Locking an application connection blocks delivery of generated data notifications to the replication-based synchronization clients.

1. In the left navigation pane, select the Applications node.

2. In the right administration pane, select the Application Connections tab.

3. Select the application connection you want to manage, and:

• If the connection is currently unlocked and you want to disable synchronization, click Lock.

• If the connection is currently locked and you want to enable synchronization, click Unlock.

4. In the confirmation dialog, click OK.

Securing Sensitive Data On-Device with DataVault

(Not applicable to Hybrid Web Container) Developers should use a data vault with device applications to securely store “secrets” on the device. Data vaults are added using the DataVault API.

The data vault holds sensitive artifacts securely, because all data or artifacts in the data vault is strongly encrypted with an AES-256 bit key. Contents can include encryption keys, user and application login credentials, sync profile settings, certificates (as BLOBS).

The data vault requires a password to unlock and access the data from the application.

Therefore, a device application must prompt the user to enter this password when the

application is opened. Once unlocked, the application can retrieve any other secrets from the vault as needed, all without prompting the user.

Administrators can define a password policy through Sybase Control Center that defines the requirements for an acceptable password. The password policy is stored in the server-side settings database and the client gets those settings when it connects to Unwired Server as part of the settings exchange protocol.

When the client receives the password policy settings, it can populate the settings objects to the data vault. The datavault stores the settings. The client uses the DataVault API to create a vault with a default password, set the password policy, and change the password to a password compatible with the policy. If the password is not changed after setting a password policy, the application will throw an exception if you then try to access the application or unlock the vault with an incompatible password.

Administrators should discuss the data vault strategy before it is implemented, especially regarding:

Failed logins – Developers can set the number of failed login attempts allowed before the data vault is deleted. Once the vault is deleted, the encrypted databases are not useable. The application needs to be re-installed, or re-initialized, including deleting the database files to recover.

Timeouts – Developers can also set a timeout value so that the data vault locks itself when it's not in use. The user must re-enter the vault password to resume using the application.

For more details about the data vault, see DataVault in the developer guide for your application type.

1. Enabling and Configuring a Password Policy for Data Vault Logins

Administrators can create a password policy for device application logins in a new or existing application connection template. A password policy ensures that user-defined passwords conform to corporate security requirements.

2. Using Login Screens for Data Vaults

An application that implements a login screen is considered to be secure. Mobile application developers are responsible for creating login screens for the applications they create. A login screen allows the device user to enter a passcode to unlock the data vault.

See also

• Using Login Screens for Data Vaults on page 130

Enabling and Configuring a Password Policy for Data Vault Logins

Administrators can create a password policy for device application logins in a new or existing application connection template. A password policy ensures that user-defined passwords conform to corporate security requirements.

A policy cannot be enforced unless developers add enforcement code to the data vault for an application. For information about creating a data vault that enforces the platform policy, see Creating a DataVault that Enforces Password Policy.

1. In the left navigation pane, click the Applications node.

2. In the right administration pane, click the Application Connection Templates tab.

3. Choose one of the following:

To create a new template with a password policy, click New.

To edit an existing template, select the name of the template and click Properties.

4. In the navigation pane, select the Password Policy category 5. In the right pane, configure the properties of the password policy.

6. Click OK.

Using Login Screens for Data Vaults

An application that implements a login screen is considered to be secure. Mobile application developers are responsible for creating login screens for the applications they create. A login screen allows the device user to enter a passcode to unlock the data vault.

A secure application that uses a login screen:

1. Prompts the user to enter the datavault passcode to open the application and get access to the local client database. If the wrong passcode is used, the application is rendered useless:

the key that encrypts and decrypts data in the vault cannot be used to access data until this code is accurately entered.

After a certain amount of time passes, the login in screen can be redeployed to prompt the user to re-enter the passcode.

2. Can be locked out after a configured number of retries.

3. Can self-destruct after a set number of incorrect passcode attempts.

When this occurs, the device user must uninstall, reinstall, then perform an initial synchronization to recover from a destroyed data vault.

To implement a login screen you must create the login and the define the password. The screen and the password unlock the DataVault. Unlocking the vault enables access to application data off-line or on-line. In contrast, Hybrid Apps can require user credentials that must be checked against Unwired Server on-line before granting access to Hybrid App content.

The password is initially defined when you configure the property values required to enable an authenticated HTTPS connection. However, you can allow users to change this password. For

information about password definition see changePassword in the Developer guide for your application type.

See also

• Securing Sensitive Data On-Device with DataVault on page 128

Provisioning Security Artifacts

Typically, you must provision Unwired Platform security artifacts before applications can be used. The manner by which an artifact is provisioned depends on the artifacts themselves, the device types used, and your deployment environment.

Provisioning methods for different application types is extensively documented in Mobile Application Provisioning. For complete details on provisioning techniques, read Stage 3:

Provision.

See also

• Modifying Default Synchronization Listener Properties with Production Values on page 104

• Establishing Encrypted Application Connections on page 132

• Unwired Server and Device Application Communications on page 4

• Encrypting Synchronization for Replication Payloads on page 101