SCENARIO 02 Okta SAML 2.0 IdP Migration SOC 2

App Migration: Legacy IdP → Okta

M&A integration required migrating a subsidiary's SaaS application portfolio off Microsoft Entra ID onto Okta within 60 days. AD Agent provisioning bug resolved at source, 9/9 SAML assertion checks passed via SAML Tracer, three break/fix scenarios executed pre-cutover, and legacy IdP disabled with rollback preserved.

Okta AD Agent SAML 2.0 SAML Tracer IdP Migration Cutover Planning SOC 2 CC6.1/CC6.3

Business Problem

IDSentinel Solutions completed the acquisition of a subsidiary operating on a separate Microsoft Entra ID tenant. The subsidiary's workforce authenticated to all SaaS applications through Entra ID as the sole SSO provider. The M&A integration mandate required consolidating the subsidiary's application portfolio onto Okta — IDSentinel's enterprise IdP — within 60 days to eliminate dual-IdP sprawl, enforce consistent access policy, and reduce licensing overhead.

A secondary blocker complicated the migration: the Okta AD Agent provisioning wizard encountered an unresolved bug on the initial trial organization. The IAM team resolved the blocker directly — provisioning a clean Integrator Free Plan organization and deploying the AD Agent successfully against it. Users provision from AD directly into Okta in a single hop with no intermediary dependency.

Risk

  • Dual-IdP operation after acquisition creates inconsistent MFA enforcement — subsidiary users not governed by IDSentinel CA policies
  • App migration without a validated rollback plan risks SSO outage for the acquired workforce
  • No centralized audit trail — sign-in logs split across two IdP tenants
  • Manual provisioning workarounds introduce orphaned account risk during the migration window
  • Non-compliant with Zero Trust mandate — all access must route through Okta
  • SOC 2 Type II exposure under CC6.1 (Logical Access Controls) and CC6.3 (Access Authorization)

Scope

ParameterDetail
Legacy IdPMicrosoft Entra ID (M365 Developer Tenant)
Target IdPOkta (Integrator Free Plan)
Provisioning pathAD → Okta AD Agent (direct)
Application migratedIDSentinel HR Portal (SAML 2.0 — simulated via samlsp.com)
Users in scopeGRP-ACCESS-HRApps (synced from AD via Okta AD Agent)
ProtocolSAML 2.0
Compliance targetSOC 2 Type II — CC6.1, CC6.3

Solution Design — 5 Workstreams

WS 1

AD → Okta Directory Integration (AD Agent)

Okta AD Agent deployed on IDS-DC. OU scope limited to HR, IT, Security, and Groups OUs. 9 pilot users selectively confirmed active — all others in pending state to stay within the Integrator Free Plan 10-user limit.

WS 2

Legacy IdP Baseline Documentation

HR Portal SAML integration in Entra ID documented in full — SP entity ID, ACS URL, NameID format, and attribute mapping captured as the rollback target and migration spec. SP-initiated SSO tested against Entra to establish a verified pre-migration baseline.

WS 3

SAML App Migration to Okta

HR Portal re-registered in Okta as a custom SAML 2.0 application using the Entra baseline as the spec. Access assigned via GRP-ACCESS-HRApps — no individual user assignments. samlsp.com updated with Okta's IdP metadata — this was the technical cutover point at the SP.

WS 4

SAML Tracer Validation + Break/Fix

SP-initiated and IdP-initiated flows validated. SAML Tracer captured and inspected the full assertion against 9 checks. Three intentional failure modes reproduced and resolved before cutover.

WS 5

Cutover and Legacy IdP Decommission

Pre-cutover checklist executed. Entra SSO configuration set to Disabled — not deleted — preserving the rollback path for 30 days per change management policy. Post-cutover SSO re-validated with SAML Tracer.

// diagrams/app-migration-architecture.png — Migration architecture — Entra legacy IdP to Okta expand
Migration architecture — Entra legacy IdP to Okta

Implementation

Workstream 1 — AD Agent and User Provisioning

  • 01

    AD Agent Confirmed Active / Attribute Mappings Verified

    AD Agent confirmed Active on IDS-DC. Attribute mappings verified in the To Okta tab — key mappings include managerDn → manager, department, title, and email. Full import executed against scoped OUs; 9 pilot users selectively confirmed active.

    // 01-directory-integration/01-ad-agent-active expand
    AD Agent confirmed Active on IDS-DC
    // 01-directory-integration/02-attribute-mapping expand
    Attribute mappings verified in To Okta tab
    // 01-directory-integration/03-import-scope expand
    OU import scope configured
    // 01-directory-integration/04a-users-confirmed-active expand
    Pilot users confirmed active

Workstream 2 — Legacy IdP Baseline

  • 02

    Entra Legacy SAML Configuration Documented

    ParameterLegacy Entra Value
    IdP Entity IDhttps://sts.windows.net/{tenant-id}/
    SP Entity IDhttps://samlsp.com
    ACS URLhttps://samlsp.com/?acs
    NameID FormatemailAddress
    // 02-legacy-baseline/05-entra-legacy-saml-config expand
    Entra legacy SAML configuration documented
  • 03

    Pre-Migration SSO Baseline Validated

    SP-initiated login tested via samlsp.com against the Entra configuration. Successful SAML assertion receipt confirmed — documented "before" state proving the legacy IdP was functional prior to migration.

    // 02-legacy-baseline/06-legacy-sso-validated expand
    Legacy SSO validated — pre-migration baseline

Workstream 3 — SAML App Migration to Okta

  • 04

    HR Portal Registered in Okta as Custom SAML 2.0 App

    IDSentinel HR Portal created in Okta using the Entra baseline values as the configuration spec.

    ParameterValue
    Single Sign-On URL (ACS)https://samlsp.com/?acs
    Audience URI (SP Entity ID)https://samlsp.com
    Name ID FormatEmailAddress
    Name ID Valueuser.email
    // 03-okta-app-registration/07-okta-app-created expand
    HR Portal app created in Okta
    // 03-okta-app-registration/08-okta-saml-settings expand
    Okta SAML settings configured
  • 05

    Attribute Statements Configured

    Four attribute statements mapped: firstName, lastName, email, and department. Department included specifically to support role-based authorization at the SP — its absence causes silent access failures without an auth error.

    // 03-okta-app-registration/09-attribute-statements expand
    Attribute statements configured
  • 06

    GRP-ACCESS-HRApps Assigned + SP Updated (Technical Cutover)

    Group assigned to the app — no individual user assignments. Okta IdP metadata downloaded and uploaded to samlsp.com — SP now trusts Okta's signing certificate. Entra is no longer in the authentication path at the SP layer.

    // 03-okta-app-registration/10-group-assignment expand
    GRP-ACCESS-HRApps assigned to app
    // 03-okta-app-registration/12-sp-metadata-updated expand
    SP updated to trust Okta — technical cutover

Workstream 4 — SAML Tracer Validation + Break/Fix

  • 07

    SP-Initiated and IdP-Initiated Login Validated — 9/9 Assertion Checks

    CheckResult
    Issuer = Okta Entity ID✅ Pass
    ACS URL correct✅ Pass
    NameID Format = EmailAddress✅ Pass
    NameID Value = user email✅ Pass
    firstName attribute present✅ Pass
    lastName attribute present✅ Pass
    email attribute present✅ Pass
    department attribute present✅ Pass
    Signature valid✅ Pass
    // 04-saml-validation/13-sp-initiated-login expand
    SP-initiated login flow
    // 04-saml-validation/15a-idp-initiated-login expand
    IdP-initiated login flow
    // 04-saml-validation/14a-saml-tracer-assertion expand
    SAML Tracer assertion — 9/9 checks passed
  • 08

    Break/Fix Scenarios Executed Pre-Cutover

    • Break 1Wrong ACS URL — trailing slash added. SAML Tracer confirmed incorrect Destination attribute. Removed — resolved.
    • Break 2Missing Attribute — department removed. SSO succeeded but no department claim in decoded assertion — demonstrates silent downstream authorization failures, not auth errors. Re-added — resolved.
    • Break 3Wrong NameID Format — changed to Unspecified. SP rejected assertion with format mismatch. SAML Tracer confirmed wrong format. Restored to EmailAddress — resolved.
    // 04-saml-validation/16-breakfix-acs-url expand
    Break/Fix 1 — wrong ACS URL
    // 04-saml-validation/17-breakfix-missing-attribute expand
    Break/Fix 2 — missing attribute
    // 04-saml-validation/18-breakfix-nameid expand
    Break/Fix 3 — wrong NameID format

Workstream 5 — Cutover and Legacy IdP Decommission

  • 09

    Pre-Cutover Checklist Executed

    PowerShell checklist script run against all migration criteria — AD Agent health, user provisioning, SAML app config, SP metadata update, both login flows, all assertion checks, and rollback readiness. All checks passed before touching the legacy configuration.

    // 05-cutover/19-pre-cutover-checklist expand
    Pre-cutover checklist — all criteria passed
  • 10

    Legacy Entra SSO Disabled

    Enterprise app SSO in Entra ID set to Disabled — not deleted. Configuration preserved for 30 days as the rollback target per change management policy.

    // 05-cutover/20-legacy-sso-disabled expand
    Legacy Entra SSO disabled — not deleted
  • 11

    Post-Cutover Validation

    Full login cycle re-run post-cutover. SP-initiated and IdP-initiated flows confirmed. SAML Tracer assertion captured as go-live evidence — issuer is Okta. Entra is no longer in the authentication path.

    // 05-cutover/21a-post-cutover-validated expand
    Post-cutover validation — Okta is sole issuer

Outcome

AD Agent deployed on IDS-DC — provisioning bug resolved at source, not worked around
9 pilot users provisioned from AD with full attribute fidelity — department, title, manager populated
HR Portal migrated from Entra SSO to Okta SAML 2.0 — 9/9 assertion checks passed
SP-initiated and IdP-initiated login flows both validated
3 break/fix scenarios reproduced and resolved pre-cutover
Legacy Entra SSO disabled — rollback window preserved for 30 days

Migration Results

MetricResult
Users provisioned AD → Okta9 (GRP-ACCESS-HRApps)
SAML assertion checks passed9 / 9
SP-initiated SSO validated✅ Yes
IdP-initiated SSO validated✅ Yes
Break/fix scenarios resolved3 / 3
Legacy IdP SSO configurationDisabled — rollback preserved
SOC 2 evidence package produced✅ Yes

SOC 2 Mapping

ControlEvidence
CC6.1 — Logical Access ControlsSAML Tracer assertion capture — NameID, attributes, and signature validated; Okta is the sole trusted IdP post-cutover
CC6.3 — Access AuthorizationGroup-based assignment in Okta — GRP-ACCESS-HRApps governs all access; no individual user assignments; pre-cutover checklist documents authorization state

Files