Create access policy rules that specify the criteria that must be met to access the Workspace ONE portal and the entitled applications as a whole. You can also create application-specific access policies with rules to manage user access to specific web and desktop applications.
Network addresses are assigned to the access policy rule to manage user access based on which IP address is used to sign in and access apps. When the Workspace ONE Access service is configured on premises, you can configure network IP address ranges for internal network access and external network access. You can then create different rules based on the network range configured in the rule.
Network ranges are configured from the Identity & Access Management tab, Manage > Policies > Network Ranges page before configuring access policy rules.
Each identity provider instance in your deployment is configured to link network ranges with authentication methods. When you configure a policy rule, ensure that the network range you select is covered by an existing identity provider instance.
Access policy rules are configured to manage the type of device used to access the portal and resources. Devices that you can specify include iOS and Android mobile devices, computers that run either Windows 10 or macOS operating systems, Web Browser, Workspace ONE & Intelligent Hub App, and All Device Types.
The policy rule with device type Workspace ONE & Intelligent Hub App defines the access policy for launching applications from the Workspace ONE or Intelligent Hub app after signing in from a device. When this rule is the first rule in the policy list, after users are authenticated, they can stay signed in to the app and access their resources for up to 90 days according to the default setting.
The policy rule with device type Web Browser defines an access policy using any kinds of web browser, regardless of device hardware types and operations systems.
The policy rule with device type All Device Types matches all cases of access.
When the Workspace ONE or Intelligent Hub app is used to access apps, the device types are organized in the policy set with Workspace ONE App device type the first rule, followed by mobile, Windows, and macOS, Web Browser device types. All Device Types is listed last. The order the rules are listed indicates the order that the rules are applied. When a device type matches the authentication method, subsequent rules are ignored. If the device type Workspace ONE App rule is not the first rule in the policy list, users are not signed in to the Workspace ONE app for the extended time. See Applying Workspace ONE App Rules to Access Policies.
You can apply different authentication rules based on user's group membership. Groups can be groups that are synced from your enterprise directory and local groups that you created in the Workspace ONE Access console.
When groups are assigned to an access policy rule, users are asked to enter their unique identifier, and then are asked to enter the authentication based on the access policy rule. See Login Experience Using Unique Identifier in the Workspace ONE Access Administration guide. By default, the unique identifier is userName. Go to the Identity & Access Management > Setup > Preferences page to see the configured unique identifier value or to change the identifier.
Actions Managed by Rules
An access policy rule can be configured to allow or deny access to the workspace and resources. When a policy is configured to provide access to specific applications, you also can specify the action to allow access to the app with no further authentication required. For this action to apply, the user is already authenticated by the default access policy.
You can selectively apply conditions in the rule that apply to the action, such as which networks, device types, and groups to include, and the device enrollment and compliance status. When the action is to deny access, users cannot sign in or launch apps from the device type and network range configured in the rule.
The authentication methods that are configured in the Workspace ONE Access service are applied to access policy rules. For each rule, you select the type of authentication methods to use to verify the identity of users who sign in to Workspace ONE or access an app. You can select more than one authentication method in a rule.
The authentication methods are applied in the order they are listed in the rule. The first identity provider instance that meets the authentication method and network range configuration in the rule 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 authentication chaining in an access policy rules to require users to pass credentials through more than one authentication methods before they can sign in. Two authentication conditions in one rule are configured and the user must correctly respond to both authentication requests. For example, if you set the authenticate using setting to Password and VMware Verify, users must enter both their password and the VMware Verify passcode before they are authenticated.
Fallback authentication can be set up to give users who fail to pass the previous authentication request another chance to sign in. If an authentication method fails to authenticate the user and fallback methods are also configured, users are prompted to enter their credentials for the additional authentication methods that are configured. The following two scenarios describe how this fallback can work.
- In the first scenario, the access policy rule is configured to require users to authenticate with their password and VMware Verify passcode. 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 VMware Verify passcode. 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 VMware Verify passcode. Fallback authentication is set up to require RSA SecurID and RADIUS for authentication. A user enters the password correctly but fails to enter the correct VMware Verify passcode. The fallback authentication request is for both the RSA SecurID credential and the RADIUS credential for authentication.
To configure an access policy rule that requires authentication and device compliance verification for Workspace ONE UEM-managed devices, Device Compliance with AirWatch must be enabled in the built-in identity provider page. See Enabling Compliance Checking for Workspace ONE UEM Managed Devices. The built-in identity provider authentication methods that can chain with Device Compliance with AirWatch are Mobile SSO (for iOS), Mobile SSO (for Android), or Certificate (Cloud Deployment).
When VMware Verify is used for two-factor authentication, VMware Verify is the second authentication method in the authentication chain. VMware Verify must be enabled in the Built-in identity provider page. See Configuring VMware Verify for Two-Factor Authentication.
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 open a specific application. For example, a value of 8 in a web application rule means once authenticated, users do not need to reauthenticate again for 8 hours.
The policy rule setting Re-authentication after does not control the application sessions. The setting controls the time after which users have to be reauthenticated.
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 that overrides the default message for each access policy rule. The custom message can include text and a link for a call to an action message. For example, in a policy rule to restrict access to devices that are enrolled, 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.