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.
