Skip to content
Event Route Optimiser Docs

Customer Google Sign-In Onboarding and Marketplace Intake

Customer Google Sign-In Onboarding and Marketplace Intake

1. Purpose

Define a repeatable one-time onboarding process for customers who require Google sign-in for ERO through Microsoft Entra External ID.

This document also defines the exact fields a customer must complete in the marketplace intake form before Synkronyx deployment begins.

2. Scope

This runbook applies to:

  • Customer Google Workspace or Cloud Identity tenants.
  • ERO identity integration through Microsoft Entra External ID.
  • Initial onboarding for one pilot user and controlled rollout.

This runbook does not replace the technical implementation detail in:

  • docs/39-ciam-google-microsoft-signin-runbook.md
  • docs/40-ciam-google-dev-test-user-flow-checklist.md

Customer and operations companion documents:

  • docs/44-customer-google-signin-marketplace-questionnaire.md
  • docs/45-customer-google-signin-post-onboarding-automation-runbook.md
  • docs/46-customer-google-signin-marketplace-portal-copy.md

3. Key Principle: Why one Google API key is not enough

Google API keys are not sufficient for identity administration tasks required for enterprise SSO.

Google sign-in federation and group administration require authenticated admin authority, usually through OAuth credentials and delegated privileges, not a generic project API key.

For Google sign-in onboarding, the minimum identity credential pair is:

  1. Google OAuth Client ID
  2. Google OAuth Client Secret

For automated group synchronization after onboarding, the customer may also provide a delegated admin automation credential set (see section 6.3).

4. Delivery model

The delivery model has two phases:

  1. One-time manual setup for trust establishment and first validation.
  2. Post-validation automation for repeatable operations (group sync, membership updates, compliance checks).

5. Marketplace intake form requirements

The customer must submit all required fields before deployment scheduling.

5.1 Organization profile (required)

  • Customer legal organization name.
  • Primary deployment region.
  • Primary business domain (example: customer.com).
  • Technical owner email.
  • Security owner email.

5.2 Google identity profile (required)

  • Google tenant type: Cloud Identity Premium or Google Workspace.
  • Verified domain used for workforce sign-in.
  • Google super admin contact email for implementation sessions.
  • Break-glass admin account confirmation.

5.3 Google federation credentials (required)

  • Google OAuth Client ID.
  • Google OAuth Client Secret.
  • Google OAuth project ID.

Security rule:

  • Secrets must never be entered as plain text into email or ticket comments.
  • Secrets must be exchanged through an approved secret handoff channel.

5.4 Entra context (required)

  • Entra tenant ID for customer identity plane.
  • Entra tenant domain.
  • Confirmation that customer approves Google as an enabled identity provider in the ERO user flow.

5.5 Pilot access scope (required)

  • Named pilot user account for first sign-in test.
  • Confirmation that pilot access is restricted to a single user or small pilot group.
  • Confirmation that local fallback sign-in remains enabled during pilot.

5.6 Operational approvals (required)

  • Change window for go-live.
  • Named approver for identity changes.
  • Rollback approver.

5.7 Optional automation onboarding fields

For customers who want automated Google group lifecycle from day one:

  • Delegated admin email for automation.
  • Service account identifier used for Google Admin SDK automation.
  • Approved Admin SDK OAuth scopes list.
  • Secret location reference for service account credential material.

6. One-time manual setup walkthrough

6.1 Customer-side manual steps

Customer identity administrators must complete:

  1. Verify domain ownership in Google Admin.
  2. Confirm two local Google admin accounts exist:
    • Platform admin account.
    • Break-glass account.
  3. Create or confirm OAuth client in Google Cloud Console.
  4. Provide OAuth Client ID and Client Secret through approved secret channel.
  5. Confirm pilot user account and test window.

6.2 Synkronyx-side manual steps

Synkronyx implementation team must complete:

  1. Configure Google identity provider in Entra External ID.
  2. Bind Google provider to the target ERO user flow.
  3. Configure pilot app redirect URIs.
  4. Confirm sign-in for one pilot user.
  5. Confirm local fallback path remains available.

6.3 Group design baseline

For each onboarding, create the following logical groups:

  1. Entra pilot users group.
  2. Entra SSO operators group.
  3. Google pilot users group.
  4. Google local admin group.
  5. Google break-glass admin group.

Source-of-truth rule:

  • Entra groups must be source of truth for workforce identity lifecycle.
  • Google groups must exist for Google-side authorization and service entitlements.

7. Validation and sign-off checklist

All checks must pass before customer go-live:

  1. Pilot user can sign in through Google path and complete ERO sign-up or sign-in.
  2. Local fallback identity path is functional.
  3. Break-glass account sign-in is verified.
  4. User flow shows only approved identity providers.
  5. Customer security owner confirms evidence.

8. Rollback criteria

Rollback must be executed if any of the following occur:

  1. Pilot user cannot complete authentication round trip.
  2. Admin access path is degraded.
  3. Unexpected user population is exposed to new SSO path.

Rollback action baseline:

  1. Remove or disable Google provider binding from the affected user flow.
  2. Revert pilot assignments.
  3. Re-run validation on local fallback and break-glass paths.

9. Customer marketplace form template

Use this template as the canonical intake form payload.

customerOrganization: ""
primaryDomain: ""
deploymentRegion: ""


technicalOwnerEmail: ""
securityOwnerEmail: ""


googleTenantType: "Cloud Identity Premium|Google Workspace"
googleVerifiedDomain: ""
googleSuperAdminEmail: ""
googleBreakGlassEmail: ""
googleOAuthProjectId: ""
googleOAuthClientId: ""
googleOAuthClientSecretReference: ""


entraTenantId: ""
entraTenantDomain: ""


pilotUserEmail: ""
pilotScopeConfirmed: true
localFallbackConfirmed: true


changeWindowUtc: ""
identityChangeApprover: ""
rollbackApprover: ""


automationRequested: false
googleAutomationDelegatedAdminEmail: ""
googleAutomationServiceAccountId: ""
googleAutomationScopes: []
googleAutomationSecretReference: ""

10. Evidence pack required at completion

Store these artifacts in the deployment record:

  1. Completed intake form.
  2. Redacted sign-in validation screenshots.
  3. User flow configuration export or screenshots.
  4. Go-live approval message from customer security approver.
  5. Rollback plan confirmation.