Posted by Jim Giseburt on 11 April 2017 05:02 PM
Google APIs support the use of the OAuth 2.0 protocol; among other things, this allows Cipafilter to securely interface with Google Apps domains for the purpose of authentication.
Two distinct but related Google authentication methods are provided by the Cipafilter software: a back-end service and a portal front-end.
Google OAuth back-end
Adding Google OAuth to the authentication services on the Content Filtering page enables the Google OAuth back-end feature. This provides for Google Apps itself to act as a directory service, bypassing the need for an LDAP server at all. When this feature is selected, the Cipafilter will check for a user's existence in Google Apps and, if applicable, derive group memberships from that user's Google Apps groups (aka distribution lists).
There are some caveats to this authentication method, however, which do not apply to the LDAP methods. Most notably, Google does not support actual credential authentication through their APIs; because of this, the Cipafilter can not directly perform user-name and password validation against Google Apps user accounts. Instead, authentication may be provided by the Google OAuth front-end feature (described below) or by a compatible Cipafilter authentication client. The authentication clients for Windows and OS X can "simulate" a successful Google log-in when the user's domain or work-station user name matches that of their Google Apps account; the authentication is assumed to be successful based on the fact that the user was able to log in to the work station.
The Google OAuth back-end does not work with browser proxy prompts or with the Cipafilter Chrome Authenticator extension.
Google OAuth front-end
Checking Use Google OAuth for portal authentication on the Content Filtering page activates the Google OAuth portal front-end. This feature enables the captive portal system to hand off authentication to Google itself, which subsequently reports the success or failure of the operation back to the Cipafilter. After confirming the success of the user's log-in, the Cipafilter can use any configured authentication service to match the user to a group.
Example: Suppose Central High School has an internal Active Directory server as well as Google Apps accounts for all students. A student named Joe Bloggs has an account
This feature can also be used in conjunction with the Google OAuth back-end (described above). By combining the two, organizations can use Google Apps as a complete substitute for more traditional directory services.
Because it requires Web-based interaction from the users themselves, the front-end feature is only beneficial to portal users; it does not affect browser proxy prompts or Cipafilter authentication clients.
Combining Google OAuth with LDAP
For organizations looking to combine traditional LDAP services with Google authentication, Google provides a free product for Windows and Linux calledGoogle Apps Directory Sync, which automatically synchronizes directory information between Google Apps and a local LDAP server.
Using this synchronization solution is generally more robust than the Google OAuth back-end, due to the limitations described above.
Google OAuth initial setup
Both the front-end and back-end Google OAuth features require a one-time setup on the Google Apps side before they can be used with the Cipafilter:
Having completed the initial configuration on the Google side, you should be able to configure the Cipafilter itself:
After following all of the steps above, you should be redirected back to the Cipafilter's Content Filtering page, where the Google Access Token field should show OK. At this point, you should be able to select any of the Google OAuth-related features you'd like to use — see those options' respective descriptions for more information.