This article describes common use cases for Context-Aware Access and includes sample configurations developed in Basic mode.
For examples of access levels developed in Advanced mode (using the CEL editor), go to Context-Aware Access examples for Advanced mode.
Allow access to contractors only through the corporate network
Many companies want to restrict contractor access to corporate resources. For example, companies who use contractors to answer general support calls or work at help centers and call centers. Similar to full-time employees, contractors must have a supported license to be covered by Context-Aware Access policies.
In this example, contractors get access to corporate resources only from a specific corporate IP address range.
| Access level name | contractor_access |
| A contractor gets access if they | Meet attributes |
| Condition 1 attribute | IP subnet 74.125.192.0/18 |
| Access level assignment | Organizational units for contractors All apps contractors use |
Block access from known hijacker IP addresses
To protect company resources from being compromised, many companies block access to known high-risk sources.
In this example, IP address 74.125.195.105 is blocked. Users get access to corporate resources if their sessions originate from any other IP address. You can specify multiple IP addresses and ranges.
| Access level name | block_highrisk |
| A user gets access if they | Don't meet attributes |
| Condition 1 attribute | IP subnet 74.125.195.105 |
| Access level assignment | Top-level organizational unit All apps |
Allow or disallow access from specific locations
If you have employees who regularly travel to remote corporate or partner offices, you can specify the geographical locations where they can access corporate resources.
For example, if a group of sales people regularly visit customers in Australia and India, you can limit the group's access to their home office and Australia and India. If they travel to other countries for a personal holiday as part of a business trip, they can’t access corporate resources from those other countries.
In this example, the sales group can access corporate resources only from the US (home office), Australia, and India.
| Access level name | sales_access |
| Sales gets access if they | Meet attributes |
| Condition 1 attribute | Geographic origin US, Australia, India |
| Access level assignment | Group of salespeople All apps salespeople use |
You could also create a policy to deny access from specific countries by specifying that users get access if they don’t meet the conditions. You would list the countries from which you want to block access.
Use nested access levels instead of selecting multiple access levels during assignment
In some cases when you try to assign access levels to a given organizational unit or group and an application (or a set of applications), you might see an error message asking you to reduce the number of applications or access levels.
To prevent this error, you can reduce the number of access levels used during assignment by nesting them into a single access level. The nested access level joins multiple conditions with an OR operation, with each condition containing an individual access level.
In this example, USWest, USEast, and USCentral are in 3 separate access levels. Let’s say you want users to be able to access applications if they satisfy any of USWest OR USEast OR USCentral access levels.You can create a single nested access level (called USRegions) using the OR operator. When it comes time to assign the access levels, assign the access level USRegions to the application for the organizational unit or group.
|
Access Level name |
USRegions |
|
A user gets access if they |
Meet attributes |
|
Condition 1 attribute (only 1 access level per condition) |
Access level USWest |
|
Join condition 1 and condition 2 with |
OR |
|
A user gets access if they |
Meet attributes |
|
Condition 2 attribute |
Access level USEast |
|
Join condition 2 and condition 3 with |
OR |
|
A user gets access if they |
Meet attributes |
|
Condition 3 attribute |
Access level USCentral |
Require company-owned on desktop but not on mobile device
A company might require a company-owned desktop device, but not a company-owned mobile device.
First, create an access level for desktop devices:
|
Access level name |
aldesktop_access |
|
Users get access if they |
Meet attributes |
|
Condition 1 attribute |
Device policy
Device encryption = Not supported Device OS macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
Then, create an access level for mobile devices:
|
Access level name |
almobile_access |
|
Users get access if they |
Meet attributes |
|
Condition 1 attribute |
Device OS iOS = 0.0.0 Android = 0.0.0 |
Require basic device security
Most enterprise companies now require employees to access corporate resources through devices that are encrypted and meet minimum operating system versions. Some also require that employees use company-owned devices.
You can configure these policies for all of your organizational units or only for those that work with sensitive data, such as company executives, finance, or human resources.
There are several ways you can configure a policy that includes device encryption, minimum operating system version, and company-owned devices. They each have advantages and disadvantages.
1 access level that contains all security requirements
For example, if a user device is encrypted and is company-owned but doesn’t run a compliant version of the operating system, they are denied access.
Advantage: Easy to set up. When you assign this access level to an app, a user has to satisfy all requirements.
Disadvantage: To separately assign the security requirements to different organizational units, you need to create a separate access level for each security requirement.
| Access level name | device_security |
| A user gets access if they | Meet attributes |
| Condition 1 attribute (You can add all attributes to one condition or create 3 conditions and join them with AND.) |
Device policy Device OS |
3 separate access levels
For example, a user who has an encrypted device and runs an older version of the operating system on a personal device gets access.
Advantage: A granular way of defining access levels. You can separately assign access levels to different organizational units.
Disadvantage: Users have to meet the conditions in only one access level.
| Access level name | device_encryption |
| A user gets access if they | Meet attributes |
| Condition 1 attribute |
Device policy |
| Access level name | corp_device |
| A user gets access if they | Meet attributes |
| Condition 1 attribute |
Device policy |
| Access level name | min_os |
| A user gets access if they | Meet attributes |
| Condition 1 attribute |
Device policy |
1 access level with nested access levels
When you assign the fourth access level to apps, users must meet the conditions in each of the 3 nested access levels to get access. It’s a logical AND of access levels.
For example, a user who has an encrypted device and runs an older version of the operating system on a personal device is denied access.
Advantage: You retain the flexibility of separating security requirements across access levels 1, 2, and 3. Using access level 4, you can also enforce a policy with all security requirements.
Disadvantage: The audit log only captures access denied to access level 4 (not to access levels 1, 2, and 3), because access levels 1, 2, and 3 aren’t directly assigned to apps.
Create 3 access levels as described in “3 separate access levels” above: “device_encryption,” “corp_device,” and “min_os.” Then create a fourth access level called “device_security” that has 3 conditions. Each condition has an access level as its attribute. (You can add only 1 access level attribute per condition.)
| Access level name | device_security |
| A user gets access if they | Meet attributes |
| Condition 1 attribute (only 1 access level per condition) |
Access level device_encryption |
| Join condition 1 and condition 2 with | AND |
| A user gets access if they | Meet attributes |
| Condition 1 attribute | Access level corp_device |
| Join condition 2 and condition 3 with | AND |
| A user gets access if they | Meet attributes |
| Condition 1 attribute | Access level min_os |
