Solutions

Control Google Apps access with ProxySG

Solutions ID:    KB4571
Version:    4.0
Status:    Published
Published date:    08/16/2011
Updated:    09/12/2012
 

Problem Description

I want to control which Google Apps domains users can get to. I want to allow users to go to Corporate Google Apps only, and not their personal or non-work related Google Apps.

Resolution

Google has added a header that can be used to control the allowed domains accessing Google Apps. This header can be used to allow Enterprise Google Apps users to allow access to their corporate domains but block access to consumer Gmail/Google Apps. By including the header X-GoogApps-Allowed-Domains in Google-bound requests and white listing a specific domain, for example company.com, Google Enterprise Apps are allowing users to authenticate to Google services using their user@company.com Google login.  So, if a user tried to log in to their personal Gmail account or their personal or non-work related domain account, they would be unable to authenticate and thus would not be able to access those services. This article describes how to achieve that control with a ProxySG solution.  Further information on this option from Google's perspective can be located by CLICKING HERE.

This control requires the SSL license on the ProxySG. This solution is written based on SGOS 6.2 but should work for most recent SGOS versions. The default policy is assumed to be Allow and therefore no additional rules are required to permit the traffic. This document will not cover the complete details of how to configure SSL interception such as keyrings and certificates. KB article KB3700 addresses how to set up SSL interception, including the necessary certificate configuration.

1.     SSL Proxy

Depending on how traffic is getting to the ProxySG, the exact method for handling SSL traffic will differ.

  • Explicit Proxy: If users' browsers are explicitly configured to connect to the ProxySG, then the Explicit HTTP service must be modified to enable the Detect Protocol option. This will cause the HTTP service to determine the appropriate protocol proxy for the traffic and hand it off for processing. In this case, that traffic will be SSL.

 

  • Transparent Proxy: If HTTPS traffic is being transparently proxied (possibly via WCCP or physically in-path), then the HTTPS service must be set to Intercept and the Proxy must be set to SSL.

 

 

  2. VPM Policy

In the Visual Policy Manager, we need to create policy to intercept SSL traffic and then add the Google-specific header.

1.     From the VPM Policy menu, select Add SSL Intercept Layer.

2.     Add a rule.

3.     In the Action column of the new rule, right-click and select Set.

4.     Click New and  select Enable HTTPS Interception.

5.     Modify the name if desired and click OK.

 

 

6. Click OK.

 

7.  From the Policy menu, select Add Web Access Layer.

8.   Modify the layer name to include GoogleApps.

9.    Add a rule.

10.   Right-click the Destination column for the new rule and click Set.

11.   Click New and select Request URL Object.

12. In the Simple Match URL, enter google.com.

 

 

13.     Click Add and Close.

14.     Click OK.

15.     In the Action column of the new rule, right-click and select Set.

16.     Click New and Control Request Header.

17.     Modify the name to include GoogleApps.

18.     Set the Header Name to X-GoogApps-Allowed-Domains. Enter your enterprise domains in the Set value field. If multiple domains are required, enter the domains separated by commas. (companya.com, company.com, companyc.com)

 

19.     Click OK and OK.

20.     Click Install policy.

 

 


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question