Google Workspace Sync

Google Workspace Sync automatically provisions users and groups from Google Workspace into your Prism realm. It is the Google equivalent of SCIM provisioning, but because Google Workspace cannot push to a custom SCIM endpoint, Prism pulls the directory from Google's Admin SDK on a schedule and reconciles it into Prism.

You configure it from Admin Portal > Preferences > SCIM, in the Google Workspace Sync card.

info

Use Google Workspace Sync when Google Workspace is your source of truth. For identity providers that support outbound SCIM (Okta, Microsoft Entra ID), use SCIM provisioning instead.

How it works

Unlike push-based SCIM, there is no SCIM token and nothing to install on the Google side beyond granting read access. Prism authenticates to Google as a service account with domain-wide delegation, reads your directory on a configurable interval, and applies the differences to Prism.

• Pull-based: Prism polls the Google Admin Directory API and performs a full reconciliation each cycle.
• Read-only: the service account is granted read-only directory scopes, so Prism never writes to Google.
• Per realm: each customer/realm has its own independent configuration.

Prerequisites

• Google Workspace super administrator access (required to grant domain-wide delegation).
• A Google Cloud project where you can enable APIs and create a service account.
• Prism admin access to the SCIM Configuration page.

Part 1: Google setup

Step 1: Create a service account and key

1. In the Google Cloud Console, select or create a project.
2. Enable the Admin SDK API (APIs & Services > Library → search "Admin SDK API" → Enable).
3. Go to APIs & Services > Credentials > Create credentials > Service account and create one.
4. Open the service account → Keys > Add key > Create new key > JSON, and download the key file.
5. Note the service account's Unique ID (a numeric OAuth client ID); you need it for delegation.

warning

The service-account JSON key grants read access to your entire directory. Store it securely, never commit it to source control, and delete the local copy once you've pasted it into Prism.

Step 2: Grant domain-wide delegation

1. In the Google Admin Console, go to Security > Access and data control > API controls > Domain-wide delegation.

2. Click Add new.

3. Client ID: paste the service account's Unique ID (numeric).

4. OAuth scopes: paste these three, comma-separated (all read-only):

   https://www.googleapis.com/auth/admin.directory.user.readonly,
   https://www.googleapis.com/auth/admin.directory.group.readonly,
   https://www.googleapis.com/auth/admin.directory.group.member.readonly

5. Click Authorize.

warning

Use the numeric Client ID, not the service-account email. Using the email results in an unauthorized_client error at sync time.

Step 3: Choose an admin to impersonate

Pick a real Google Workspace admin user (for example, admin@yourdomain.com). The service account impersonates this user to read the directory, and Google authorizes the read based on that user's permissions, so it must be an administrator with directory-read rights.

info

The impersonated admin must remain a valid, privileged admin, or every sync for the realm will fail. Point it at a stable, dedicated admin account rather than an individual who might leave.

Part 2: Configure in Prism

1. Go to Admin Portal > Preferences > SCIM and find the Google Workspace Sync card.
2. Fill in:
   • Admin email (impersonated): the admin chosen in Step 3.
   • Service account JSON key: paste the full contents of the JSON key file.
   • Sync interval (minutes): how often to reconcile (default 15).
3. Click Save configuration. The key is encrypted at rest and is never displayed again.
4. Click Sync now to run an immediate reconciliation, then watch the status line (enabled/disabled · last sync time · success/error).
5. Once the test sync looks correct, turn on Enable scheduled sync and Save, and Prism then reconciles automatically on the configured interval.

info

When editing an existing configuration, you can leave the Service account JSON key field blank, and Prism keeps the stored key. You only need to paste a key on first setup or when rotating it.

What gets synced

Change in Google Workspace	Result in Prism
User added	User created (or an existing same-email Prism user adopted)
User first/last name changed	User updated
User email changed	No change (email is immutable; see below)
User suspended	User disabled
User unsuspended	User re-enabled
User deleted	User disabled, not deleted (reversible)
User re-created after deletion	Re-adopted and re-enabled
Group added	Group created
Group renamed	No change (group names are not updated; see below)
Group deleted	Group deleted in Prism
Member added / removed	Group membership added / removed

Email is immutable

Email addresses are immutable in Prism's business logic. If a user's primary email changes in Google Workspace, Prism does not change that user's email. The user continues to be matched by their stable Google user ID, and other attributes (name, enabled/disabled status) are kept in sync, but the email remains as it was originally provisioned.

Group names are not updated

Renaming a group in Google Workspace does not rename the corresponding group in Prism. Group names are set once, at creation. This is intentional: permission-set assignments are keyed by group name, so renaming a synced group would orphan its assignments. Treat synced group names as fixed.

Coexistence with other identity sources

Google Workspace Sync only manages the resources it creates. Users and groups provisioned by other identity providers (Okta, Microsoft Entra ID) or created manually are never modified or deleted by the sync. If a Google user's email matches an existing Prism user, that user is adopted, and Google becomes its source of truth from then on (last write wins).

Deprovisioning

• Users removed or suspended in Google Workspace are disabled in Prism, never deleted. This is reversible: restoring the user in Google re-enables them on the next sync.
• Groups removed from Google Workspace are deleted in Prism.

danger

Remove a synced group's permission-set assignments before deleting or un-syncing the group in Google Workspace. When the group is deleted, Prism deletes the corresponding group, but its permission-set assignments are not cleaned up automatically, which silently revokes access for the group's members and leaves orphaned assignments. Always detach the assignments in Prism first, then delete the group in Google.

Scheduled vs. manual sync

• Enable scheduled sync runs reconciliation automatically on the configured interval.
• Sync now runs an immediate reconciliation. It works even when scheduled sync is disabled, which is useful for testing the configuration before turning it on.

Troubleshooting

Symptom	Likely cause	Fix
"google sync disabled" when saving	Encryption key not configured on the server	Contact your Prism operator (server-side configuration)
Status error: unauthorized_client / 403	Domain-wide delegation missing or wrong scopes	Re-check the Client ID (numeric) and the three read-only scopes
Status error: invalid credentials / impersonation failed	Impersonated email isn't a valid admin, or the Admin SDK API isn't enabled	Verify the API is enabled and the impersonated user is an administrator
Sync succeeds but no users appear	Wrong impersonated admin, or filtered/empty directory	Confirm the admin's domain contains the expected users
"serviceAccountJson must be a valid service-account key"	Wrong file pasted	Paste the JSON whose type is service_account
A user lost group access after a group was removed	Group deleted in Google → orphaned assignments	See the deprovisioning warning above; rebuild the assignments