Context-Aware Access

Versions: Standard and Plus

Context-Aware Access is how to limit a user's access to a given service within Google based on criteria. That criteria can be geolocation, 2-step Verification, IP address, or whether access is from an approved device. The criteria, called access levels in Google Workspace, can apply to users, groups, and organization units. You can use several criteria markers to determine which users are within or out of scope, based on the context of defined access levels.

One of the big things to be aware of is that Context-aware access does not prevent access to other services or services outside of the defined scope, and it does not prevent users from signing into the account. It only prevents access to the Google service(s) covered by the scope.

Warning: Context-aware access does not stop users from signing in. It prevents them from accessing services.

Context-Aware Examples

Now that we know what Context-Aware access is, let's look at some examples of how it applies to education. Later in this article, we will cover how to create one of these examples.

Restricting an app by time frame

If you want a group of users to only use an app during a set time, you can restrict their access to the blocked-out hours. Maybe you do not want students to use Chat or staff to use Gmail outside of school hours. When restricting staff access to Gmail, staff members cannot use their email outside school hours. They can only check and send emails during working hours.

When access is not permitted, the service is still working. A third party can still send an email to a staff member, but the user cannot check their email nor send or receive emails. They have no way of knowing that an email came in.

Reducing VPN Access by location

Let's say you want to reduce VPN access, specifically when utilizing a VPN to access content outside an expected area. If you know your school's public IP address and send all proxies back into the IP, you can restrict account access by users outside of the United States of America. This Context-Aware Access prevents direct access to the account from someone on foreign soil.

Remember earlier when we covered knowing what it is vs. what it isn't? In this latest example, users can circumvent the access rule by VPNing into the United States. Once on the VPN, they can access any service.

Configuration

Warning: Context-aware access is a paid feature available with the Standard and Plus versions of Workspace. For the feature to work, admins must apply the licenses to end users. What does that mean? If you set up Context-aware access and configure it for the user OU but have yet to apply the end-user licenses, the access rule will do nothing. 
As long as a user has a Workspace for Education Standard or Plus license assigned, Context-Aware Access levels set for the group or OU users are in will apply to their account.

There are a few steps to take before you can use Context-Aware Access, including:

  1. Set up software for desktop or mobile devices, if needed.
  2. Turn on Context-Aware Access.
  3. Create an access level.

See Set up software and create Context-Aware access levels for more information on the steps above.

With the setup complete, it’s time to assign access levels to apps, groups, and the Admin console.

Example: Build a Network-Based Context-Aware Rule

Now we are ready to build a Context-Aware Rule. We'll create a basic rule restricting access to only those on our organization's network. If you'd like to build an advanced rule see Context-Aware Access examples for Advanced mode.

  1. Go to Context-Aware Access.
    Admin console > Security > Access and data control > Context-Aware Access
  2. If OFF, set Context-Aware Access to ON.
  3. Click the Access levels card.
  4. Click Create Access Level, located at the right above the list.
  5. Fill in the Details section Access level name and Description.
    Pro Tip: Choose a name and description here that reflects the restriction rather than the people or groups it applies to and that you or other admins can quickly identify.
  6. In the Conditions section, select Add Condition.
  7. Meets all Attributes (AND) is auto selected for the Allow access to apps or apply rule if a user field.
  8. Click Select attribute.
  9. In the Attribute drop-down list, select IP subnet.
  10. The condition defaults to is.
  11. In the IP subnet field, enter an IPv4 or IPv6 address, or a routing prefix in CIDR block notation.
    Note: In this example, there is only one condition. Once you build these conditions out, a rule can have multiple conditions. You determine if the rule grants access if it meets or does not meet those listed conditions. The easiest way to remember how to set this is whatever you have your rule set as it is true when we apply it, they get access; if the rule is false with the request, it denies access. Remember the underlying service must be ON, if it is OFF, the user will never get access. ContextAware1.png
  12. Click Create.
  13. At the What’s next prompt, click Assign Access Level. The Assign access levels page opens.
    Note: If the user has no rules for applying for access by group or OU, they are always granted access. If they have one or more rules applied that they fall under, if any of the rules are true, they are granted access; if not, then they are denied access. Users will see a message when denied access, either a default message, a remediation message that is system generated, giving steps not to be denied, or a custom message. See the end of this article for more information on remediation messages and custom messages. ContextAware1b.png
  14. For this example, we will apply it to an OU. Navigate to the OU the rule applies to.
    Caution: If you are following along and building this example, use a test OU before applying it to your environment.
  15. Check the checkbox next to an app to select it, or check the select all checkbox at the top to select all apps. In this example, we are selecting all.
  16. Click Assign above the apps list. Be sure not to click Assign at the top right, or else you will assign the access level to the Admin console, potentially locking out all admins.
    ContextAware2.png
  17. Check the necessary Access levels. Here, we are selecting the access level we created earlier.
    ContextAware3.png
  18. Click Save. You'll see the access level assignment in the Access level column for each app you assigned.
    ContextAware4.png

User message - access denied

In this example, when a user is not on the designated IP, they will be denied access when they try to access any of the applied apps.
ContextAware5.png

Remediation message

End-user remediation will enable admins to provide their users with details about why their access has been denied and what steps need to be taken to restore it. For more information, see Allow users to unblock apps with remediation messages in Context Aware Access.
Security > Context-Aware Access > User Message

Custom user message

You can customize the message your user sees from the Context-Aware Access page in the Admin console. When customizing messages, add descriptive text to help your staff understand what the user is experiencing.
Security > Context-Aware Access > User Message

Monitoring CAA rules with the Investigation Tool

Once you have a rule in place, you can check its enforcement in the Investigation Tool. Once you investigate, you can also build an activity rule or create a custom chart for the information.

Ready to upgrade?

If you do not have an upgraded version of Workspace and would like to learn more about implementing context-aware features, learn more about upgrading your Google Workspace for Education edition.

Document Version Date Description of Change
1.0 3/18/2024 Updated link to open in a new tab
1.1 8/28/2024 Minor text updates, reverify
1.2 11/12/2024 Updated warning for user license assign

 

Articles in this section