You create access policy rules to specify the criteria that users must meet to access the Workspace ONE workspace and their entitled apps. You can also create application-specific access policies with rules to manage user access to specific web and desktop applications.
Network Range
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.
Device Type
Access policy rules are configured to manage the type of device used to access the portal and resources.
- All Device Types is configured in a policy rule that is used in all cases of access.
- Web Browser device type is configured in a policy rule to access content from any web browser, regardless of device hardware type or operating system.
- Workspace ONE App or Hub App device type is configured in a policy rule to access content from the Workspace ONE or Workspace ONE Intelligent Hub apps after signing in from a device.
- iOS device type is configured in a policy rule to access content from both iPhone and iPad devices.
In Workspace ONE Access cloud tenant environments, the iOS device type matches both iPhones and iPad devices, regardless of whether the Request Desktop Sites in Safari settings is enabled or not.
- macOS device type is configured to access content from devices configured with macOS.
For on-premises environments, also configure the macOS device type to match iPad devices that have Request Desktop Sites in Safari settings enabled.
- (Cloud Only) iPad device type is configured in a policy rule to access content from iPad devices configured with the iPadOS. This rule allows you to identify an iPad regardless of whether the Request Desktop Sites in Safari settings is enabled or not.
Note: When an access policy rule is created to use the iPad device type, the rule for iPad devices must be listed before the rule that uses the iOS device type. Otherwise the rule for iOS device type is applied to iPad devices requesting access. This applies to iPads with iPadOS or an earlier iOS.
- Android device type is configured to access content from Android devices.
- Windows 10 device type is configured to access content from Windows 10 devices.
- Windows 10 Enrollment device type. is configured to access content from Windows 10 devices that are managed by the Workspace ONE UEM service to access web apps that have restricted access.
- Device Enrollment device type is configured to require device enrollment. This rule requires that users are authenticated into the Workspace ONE UEM enrollment process facilitated by the Workspace ONE Intelligent Hub app on an iOS or Android device.
The order the rules are listed Identity & Access Management > Policies page 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.
Add Groups
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.
Authentication Methods
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 tor 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 in Workspace ONE Access. 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 in Workspace ONE Access.
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.
