Our SSO implementation for Google Apps is using OAuth and not a SAML assertion.  As such, this is why we require that a user in the Google Apps domain authorize the OAuth app that we use to read group memberships of users attempting to access the platform.  A user needs to belong to one (and only one) group within the GApps domain.

"Why do you require Admin group management API access?"
- As mentioned above, read-only access to the Admin Group Management API is required to read group membership of users.  We typically recommend that a Super Admin authorize the OAuth app to ensure that the proper permissions are available.  As with all OAuth apps, the permissions that we are requesting are stated on the authorization page.

"What are all the activities being performed when the Google Admin clicks the CloudHealth setup URL?  What will it change on my Google directory?"
- Being an OAuth application, it follows the typical OAuth model:  https://developers.google.com/identity/protocols/OAuth2.  Other than adding an additional authorized application to the list of OAuth applications authorized by that user, we do not make changes to your Google Apps directory

"When setting up Google SSO with other apps, they generally require things like a certificate, ACS URL, entity ID etc.  Why don't you require these things?"
- We made a decision to implement SSO via Google using OAuth versus a SAML assertion.  If you would like to use a SAML assertion instead, we do not support SAML via Google Apps but do support SAML via other Identity Providers such as Okta, OneLogin, and others.

"Why does this process attach to the Super Admin account?"
- We recommend a Super Admin to ensure that the proper API permissions are in place for us to read group memberships, namely read-only access to the Admin Group Management API.