Control access to apps based on user & device context

Create Context-Aware access levels

Context-Aware access levels combine conditions and values that define a user or device context. These 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.

Note: Before creating an access level, you should deploy endpoint verification and turn on Context-Aware access. Go to Set up endpoint verification and Turn on Context-Aware Access in Deploy Context-Aware Access for details.

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. 

Note: When you modify an access level, the changes take effect immediately. Be aware that changes to access levels will affect your users as soon as you make the changes. Be sure the changes are what you intend.

Expand section  |  Collapse all & go to top

Define access levels—Basic mode

  1. Select Access levels.
    You see a list of defined access levels. Access levels are a shared resource between Google Workspace 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: We recommend that you do not use the Google Cloud Platform (GCP) interface to add or modify Context-Aware access levels if you are a Workspace-only customer. If you add or change access levels using a method other than the Context-Aware access interface, this error message may result: Unsupported attributes are being used on Google Workspace, and users can be blocked.

  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.
      • Private IP addresses are not supported (including user's home networks). 
      • Static IP addresses are supported.
      • To use a dynamic IP address, you must define a static IP subnet for the access level. If you know the range of the dynamic IP address and the defined static IP address in the access level covers that range, access is granted. Access is denied when the dynamic IP address is not in the defined static IP subnet. 
    • Location—Countries/regions where the user is accessing Google Workspace services. Devices with internal IP addresses are not supported because those IP addresses are not globally unique.
    • 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 password protected

        Note: For Windows OS, this attribute checks if the sign-in screen is displayed after an inactivity timeout, which is true if either the "Require sign-in" setting (in Sign-in options) or "On resume, display login screen" setting (in Screen saver settings), is turned on. It doesn't check whether the password is set.

      • 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.
  9. Choose what to do with the access level:
    • Assign this access level to apps.
    • Create a data protection rule with this access level. If you choose this option, you'll start the rule creation wizard. Learn more about combining data protection rules with Context-Aware Access levels.

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 originating device 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?
Search
Clear search
Close search
Google apps
Main menu