When Identity Providers Change
Identity Provider migrations happen for predictable reasons:
- Acquisitions: The acquiring company standardizes on Okta; the acquired company used Google Workspace.
- Enterprise maturity: A startup on Google Workspace grows to need Okta’s advanced features (lifecycle management, advanced MFA, Universal Directory).
- Consolidation: Multiple business units on different IdPs consolidate to one.
- Compliance: Regulatory requirements mandate specific identity capabilities that the current IdP doesn’t provide.
When the IdP changes, everything authenticated through it is affected: cloud console access, SaaS apps, internal tools — and JIT access platforms.
The concern for security teams: does changing our IdP break our access governance? If JIT access is tied to Google Workspace SSO, and we’re moving to Okta, is there a gap where JIT doesn’t work? Do developers need to re-learn a workflow?
The short answer: no gap, no workflow change. The transition is a configuration update, not a re-architecture.
What Changes (and What Doesn’t) During IdP Migration
What Changes
| Component | Before | After |
|---|---|---|
| Authentication to Cloudanix | “Sign in with Google” | “Sign in with Okta” |
| Identity source for AWS Identity Center | Google SCIM sync | Okta SCIM sync |
| User identifiers | user@company.com (Google) | user@company.com (Okta) |
| Group source | Google Workspace groups | Okta groups |
| MFA provider | Google Authenticator / Security Key | Okta Verify / configured factors |
What Doesn’t Change
| Component | Status |
|---|---|
| JIT request workflow (Slack/Teams/Console) | Unchanged |
| Approval mechanics (one-click, multi-level) | Unchanged |
| Auto-approval policies | Unchanged (if group names are maintained) |
| Audit trail format | Unchanged |
| Permission sets in IAM Identity Center | Unchanged |
| Account assignments | Unchanged |
| Duration policies | Unchanged |
| Developer experience (“request access, get approved, work”) | Unchanged |
The JIT workflow is IdP-agnostic. Developers request access. Approvers approve. The platform provisions. The IdP determines how you prove who you are — not how access governance works.
The Migration Path
Step 1: Prepare the New IdP (Okta)
Before switching anything:
- Create matching groups in Okta that mirror your Google Workspace groups (Engineering, DevOps, Customer Success, etc.).
- Ensure user emails match across both IdPs. If user@company.com exists in Google Workspace, the same email should exist in Okta. This is what links the identity across the transition.
- Configure SCIM provisioning from Okta to AWS IAM Identity Center (if you’re using Okta as the Identity Center identity source).
- Validate MFA is configured for all users in Okta before cutover.
Step 2: Update AWS IAM Identity Center
IAM Identity Center needs to know its new identity source:
- Switch the Identity Center identity source from Google (or external SAML provider) to Okta.
- Verify SCIM sync is pushing users and groups correctly.
- Confirm permission set assignments still reference valid groups (if group names changed, update assignments).
This is the AWS side of the migration. Cloudanix reads from Identity Center — so once Identity Center sees the Okta-sourced users and groups, Cloudanix sees them too.
Step 3: Update Cloudanix SSO Configuration
Change the Cloudanix authentication method:
- In Cloudanix Console settings: Update the SSO provider from Google to Okta.
- Configure SAML/OIDC with Okta application details (client ID, issuer URL, callback URLs).
- Test: One admin logs in via Okta SSO to verify the flow works.
After this step, the Cloudanix login page shows “Sign in with Okta” instead of “Sign in with Google.”
Step 4: Verify JIT Policy Mappings
If group names in Okta match the previous Google Workspace group names:
- No policy changes needed. JIT policies reference group names. Same names = same policies.
If group names differ:
- Update JIT policies to reference the new group names.
- Example: Google had “eng-team” → Okta has “Engineering” → update the policy mapping.
Step 5: Communicate and Cut Over
- Tell developers: “Starting Monday, sign into Cloudanix with Okta instead of Google. Everything else works the same.”
- Parallel period (optional): Some organizations run both IdPs briefly, allowing login via either. Cloudanix supports this during transition.
- Cut over: Disable Google SSO in Cloudanix. Okta is now the sole authentication path.
Step 6: Verify End-to-End
After cutover:
- Engineer signs in with Okta SSO → Cloudanix dashboard loads.
- Engineer requests JIT access via Slack → request is created with their Okta identity.
- Approver approves → access is granted in IAM Identity Center.
- Engineer’s SSO portal (now Okta-federated) shows the role.
- Access auto-revokes → role disappears.
The workflow is identical. Only the login screen changed.
Handling the ssosync Scenario
Some organizations use ssosync (or similar tools) to sync users and groups from Google Workspace to AWS IAM Identity Center. This open-source tool runs periodically, creating and updating users in Identity Center based on Google Workspace directory changes.
During migration to Okta, this tool needs to be replaced:
- Disable ssosync (it’s still syncing from Google).
- Enable Okta SCIM provisioning to Identity Center.
- Verify users aren’t duplicated (ssosync-created users vs. Okta-provisioned users).
One specific issue to watch: if ssosync refreshes User IDs in Identity Center differently than Okta SCIM provisioning does, JIT mappings that reference specific user IDs may break. The fix: after Okta provisioning is active, trigger a sync refresh in Cloudanix to pick up the new user IDs from Identity Center.
What Developers Experience
Before Migration
- Open Cloudanix → “Sign in with Google” → Dashboard.
- Request access in Slack → Approved → Access in AWS SSO portal (Google-federated).
After Migration
- Open Cloudanix → “Sign in with Okta” → Dashboard.
- Request access in Slack → Approved → Access in AWS SSO portal (Okta-federated).
The functional experience is identical. The visual difference: a different SSO button, and potentially a different AWS SSO portal URL (if the Identity Center instance changed). Developers don’t need training. They don’t need new skills. They just authenticate differently.
Timeline and Risk
| Phase | Duration | Risk |
|---|---|---|
| Okta preparation (groups, users, SCIM) | 1–2 weeks | None (parallel to current operation) |
| Identity Center source switch | 1 hour (planned maintenance) | Medium (users may need to re-authenticate) |
| Cloudanix SSO update | 15 minutes | Low (configuration change) |
| JIT policy verification | 30 minutes | Low (name matching check) |
| End-to-end validation | 30 minutes | Low (testing) |
| Total JIT disruption | Under 2 hours (during planned window) |
The actual JIT disruption is minimal: the time between “old SSO disabled” and “new SSO confirmed working.” With preparation done in advance, this window can be under 2 hours — scheduled during low-traffic periods.
Key Takeaway: JIT Is IdP-Agnostic by Design
JIT access governance sits above the identity provider layer. It consumes identity (who is this person? what group are they in?) but doesn’t depend on which system provides that identity. Google, Okta, Azure AD, JumpCloud — they’re all identity sources. The JIT workflow (request → approve → provision → revoke → audit) is the same regardless.
This architectural separation means IdP migrations are routine configuration changes, not re-implementations. Your access governance survives organizational changes, IdP transitions, and vendor switches without losing continuity.
Planning an IdP Migration?
If you’re moving from Google Workspace to Okta (or any IdP transition) and you’re concerned about JIT access continuity — the migration is a configuration update, not a re-architecture. Same policies, same workflows, same audit trail. Different login button.
Learn more about supported identity providers or book a demo to discuss your IdP migration timeline.
