Control access to apps based on user & device context

Set up software and create Context-Aware access levels

The first step in setting up Context-Aware access is to create access levels that combine conditions and values that define a user or device context. Access levels define the context within which users can access apps.

For example, you can create an access level for accessing Gmail that requires users to connect from a specific IP address range and require their devices to be encrypted.  

Let’s say that Mary is using Gmail on her laptop in the corporate office and then walks to a nearby coffee shop where she plans to continue using Gmail. Because her IP address changed, she won’t be able to access Gmail at the coffee shop if you specify that users connect to Gmail from a corporate IP address range. Private IP addresses are not supported.

Step 1: Set up software for desktop or mobile devices

Software setups for desktop or mobile devices.

Set up desktop (endpoint verification)

If you enforce a device policy in an access level, you and your users have to set up endpoint verification. You enable endpoint verification in the Admin console. For instructions see Turn endpoint verification on or off.

To review which devices have endpoint verification, from the Admin console home page, go to Devicesand thenEndpoints. Click Add a filter, select Management Typeand then Endpoint Verification, and click Apply.

Set up mobile devices (Google endpoint management)

Mobile devices must be managed with Google endpoint management.

To enforce access levels based on company ownership or encryption, the user of the device must be under advanced mobile management.

To enforce access levels based on approval or password status, the user of the device can be under basic or advanced mobile management.

Additional steps

Upload your device inventory of company-owned devices

To enforce a device policy that requires company-owned devices, Google needs a list of serial numbers for your company-owned devices.

For instructions, see in “Add devices to your inventory in Add company-owned devices to the inventory.
Note: Devices with Android 12 or later and a work profile are always reported as user-owned, even if you add them to the company-owned inventory. For these devices, if an access level requires that a device is company-owned, the action isn’t taken, and if an access level requires that a device is user-owned, the action is taken.

Approve or block devices

To enforce a device policy that requires approved devices, first you have to approve or block devices.

Step 2: Turn on Context-Aware Access

You can turn on Context-Aware Access at different times in the rollout process. You can turn it on before creating access levels and assigning them to apps, which means that access levels you assign to apps are enforced immediately.

You can also do initial setup and review (access level creation, access level assignment, endpoint verification) without turning on Context-Aware Access. During this time, access level assignments aren’t enforced. When the configuration is complete, you can turn on Context-Aware Access.

To turn on Context-Aware Access:

  1. Sign in to your Google Admin console.

    Sign in using your administrator account (does not end in @gmail.com).

  2. From the Admin console Home page, go to Securityand thenContext-Aware Access.
  3. Verify Context-Aware Access is “ON for everyone”. If not, click Turn On.

""

Step 3: Create an access level

Access levels consist of one or more conditions that you define. To access apps, users must meet the conditions. Access-level conditions contain attributes you can select, such as device policy, IP subnet, or another access level.

You can create access levels in 2 different modes, Basic and Advanced. Basic mode provides you with a list of predefined attributes that you can select. If you need to use attributes that are not in the interface, build a custom access level in Advanced mode instead. 

Define access levels—Basic mode

""

  1. Select Access levels.
    You see a list of defined access levels. Access levels are a shared resource among Google Workspace, Cloud Identity, and Google Cloud, so you might see access levels that you didn’t create in the list. To indicate which team created an access level, consider making the platform part of the access-level name.
  2. On the top right, select Create access level.
    Basic mode is selected by default. You’ll define the access level by adding one or more conditions to it. Then define each condition by specifying one or more attributes.

    Note that if you add access level conditions using a method other than the Context-Aware access interface (while in Basic mode), this error message may result: Unsupported attributes are being used on Google Workspace.

  3. Add an access level name and optional description.
  4. For the access level condition you add, specify if the condition applies when users:
    • Meet attributes—Users must satisfy all the attributes in the condition.
    • Don’t meet attributes—Users don’t meet any of the attributes in the condition. This option specifies the opposite of the condition and is most frequently used for IP subnet attributes. For example, if you specify an IP subnet and “don’t meet,” only users with IP addresses outside of the specified range will match the condition.
  5. Click Add Attribute to add one or more attributes to the access level condition. The attributes you can add are:
    • IP subnet—IPv4 or IPv6 address or routing prefix in CIDR block notation. Note that private IP addresses are not supported
    • Geographic origin—Countries/regions where the user is accessing Google Workspace services.
    • Device policy (only choose the devices policies you need to implement)—
      • Admin approval is required (if required, the device must be approved)
      • Company owned device is required
      • Screen lock is required
      • Device encryption (Not supported, Not encrypted, Encrypted)
    • Device OS (users can only access Google Workspace with the operating systems you select. Set a minimum operating system version, or allow any version. Use the format major.minor.patch for the operating system version)—
      • macOS
      • Windows
      • Linux
      • Chrome OS
      • iOS
      • Android
    • Access level (must meet the requirements of an existing access level).
  6. To add another condition to the access level, click Add condition and add attributes to it.
  7. Indicate the conditions users must meet:
    • And—Users must meet the first condition and the added condition.
    • Or—Users must meet only one of the conditions.
  8. When you’ve finished adding access level conditions, save the access level definition by clicking Save. Now you can assign this access level to apps.

Sample access level—created in Basic mode

This example shows an access level called “corp_access.” If “corp_access” is applied to Gmail, users can access Gmail only from an encrypted and company-owned device, and only from the US or Canada.

Access level name corp_access
A user gets access if they Satisfy all the attributes in the condition
Condition 1 attribute

Device policy
   Device encryption = encrypted
   Company-owned device = required

Join condition 1 and condition 2 with AND
A user gets access if they Satisfy all the attributes in the condition
Condition 2 attribute

Geographic origin
   Countries = US, Canada

 

For more examples, see Context-Aware Access examples for Basic mode.

Define access levels—Advanced mode

This mode allows you to create access levels that can’t be created in the Context-Aware Access interface condition builder. For example:

  • The administrator might need to create access levels that include vendor conditions for third-party integrations.
  • Some advanced attributes are not accessible from the Basic mode condition interface, such as the ability to use certificate-based authentication.

In this mode, you build your custom access level in an editing window using Common Expression Language (CEL)

To define access levels using Advanced mode:

  1. Select Access levels.
    You see a list of defined access levels. Access levels are a shared resource among Google Workspace, Cloud Identity, and Google Cloud, so you might see access levels that you didn’t create in the list. To indicate which team created an access level, consider making the platform part of the access-level name.
  2. Select Create access level.
  3. Select Advanced Mode.
  4. Add an access-level name and optional description.
    You define the access level by writing a CEL expression.
  5. Build your custom access level in the CEL expression editor. 
    To do so, you need some experience with CEL. For guidance and examples of supported expressions for creating custom access levels, go to the Custom access level specification .
  6. Click Save.
    The expression is compiled and any syntax errors are reported.
    • If there are no syntax errors, your custom access level is saved, and you can assign it to apps.
    • If there are syntax errors, you see the message Fix errors to continue with compiler errors (in English only) specific to the expression you just created. You can correct the error and save again. When the custom access level contains no errors and is saved, you can assign this access level to apps.

Sample access level—created in Advanced mode

This example shows an access level that requires the following conditions be met in order to allow a request:

  • The device that the request originated from is encrypted.
  • One or more of the following is true:
    • The request originated in the United States.
    • The device that the request originated from is approved by the domain administrator.

 device.encryption_status == DeviceEncryptionStatus.ENCRYPTED && (origin.region_code in ["US"] || device.is_admin_approved_device)

For more examples, see Context-Aware Access examples for Advanced mode.

What's next: assign access levels to apps


Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.

 

Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

Search
Clear search
Close search
Google apps
Main menu
Search Help Center
true
73010
false