A policy contains one or more access rules. Each rule consists of settings that you can configure to manage user access to their Workspace ONE portal as a whole or to specific Web and desktop applications.
A policy rule can be configured to take actions such as block, allow, or step-up authenticate users based on conditions such as network, device type, AirWatch device enrollment and compliant status, or application being accessed.
For each rule, you determine the user base by specifying a network range. A network range consists of one or more IP ranges. You create network ranges from the Identity & Access Management tab, Setup > Network Ranges page before configuring access policy sets.
Each identity provider instance in your deployment links network ranges with authentication methods. When you configure a policy rule, ensure that the network range is covered by an existing identity provider instance.
You can configure specific network ranges to restrict from where users can log in and access their applications.
Select the type of device that the rule manages. The client types are Web Browser, Workspace ONE App, iOS, Android, Windows 10, OS X, and All Device Types.
You can configure rules to designate which type of device can access content and all authentication requests coming from that type of device use the policy rule.
In the policy rule, you set the order that authentication methods are applied. The authentication methods are applied in the order they are listed. The first identity provider instance that meets the authentication method and network range configuration in the policy is selected. The user authentication request is forwarded to the identity provider instance for authentication. If authentication fails, the next authentication method in the list is selected.
You can configure access policy rules to require users to pass credentials through two authentication methods before they can sign in. If one or both authentication method fails and fallback methods are also configured, users are prompted to enter their credentials for the next authentication methods that are configured. The following two scenarios describe how this authentication chaining can work.
In the first scenario, the access policy rule is configured to require users to authenticate with their password and with their Kerberos credential. Fallback authentication is set up to require the password and the RADIUS credential for authentication. A user enters the password correctly, but fails to enter the correct Kerberos authentication credential. Because the user entered the correct password, the fallback authentication request is only for the RADIUS credential. The user does not need to reenter the password.
In the second scenario, the access policy rule is configured to require users to authenticate with their password and their Kerberos credential. Fallback authentication is set up to require RSA SecurID and a RADIUS for authentication. A user enters the password correctly but fails to enter the correct Kerberos authentication credential. The fallback authentication request is for both the RSA SecurID credential and the RADIUS credential for authentication.
To configure an access policy rule requires authentication and device compliance verification, Device Compliance with AirWatch must be enabled in the build-in identity provider page. See Configure Access Policy Rule for Compliance Checking.
Authentication Session Length
For each rule, you set the number of hours that this authentication is valid. The re-authenticate after value determines the maximum time users have since their last authentication event to access their portal or to start a specific application. For example, a value of 4 in a Web application rule gives users four hours to start the Web application unless they initiate another authentication event that extends the time.
Custom Access Denied Error Message
When users attempt to sign in and fail because of invalid credentials, misconfiguration or system error, an access denied message is displayed. The default message is Access denied as no valid authentication methods were found.
You can create a custom error message for each access policy rule that overrides the default message. The custom message can include text and a link for a call to action message. For example, in a policy rule for mobile devices that you want to manage, if a user tries to sign in from an unenrolled device, you can create the following custom error message. Enroll your device to access corporate resources by clicking the link at the end of this message. If your device is already enrolled, contact support for help.
Example Default Policy
The following policy is an example of how you can configure the default policy to control access to the apps portal and to Web applications that do not have a specific policy assigned to them.
The policy rules are evaluated in the order listed in the policy. You can change the order of the rules by dragging and dropping the rule in the Policy Rules section.
For the internal network two authentication methods are configured for the rule, Kerberos and password authentication as the fallback method. To access the apps portal from an internal network, the service attempts to authenticate users with Kerberos authentication first, as it is the first authentication method listed in the rule. If that fails, users are prompted to enter their Active Directory password. Users sign in using a browser and now have access to their user portals for an eight-hour session.
For access from the external network (All Ranges), only one authentication method is configured, RSA SecurID. To access the apps portal from an external network, users are required to sign in with SecurID. Users sign in using a browser and now have access to their apps portals for a four-hour session.
This default policy applies to all Web and desktop applications that do not have an application-specific policy.