Overview
Okta and SailPoint together form a common enterprise IAM stack: Okta handles authentication, SSO, and session policy; SailPoint handles access governance, certification, and audit evidence. The challenge is that both platforms can provision users and manage entitlements—if you don't establish clear boundaries, you get "dueling provisioning engines" that create drift, audit confusion, and operational chaos.
The fundamental question: Who owns what? Both platforms have lifecycle management capabilities. Both can provision to downstream apps. Both can manage groups. Without explicit boundaries, you'll spend more time debugging conflicts than delivering value.
The recommended model:
- Okta owns authentication: SSO, MFA, session policy, sign-in risk
- SailPoint owns governance: Access requests, approvals, certifications, audit evidence
- SailPoint provisions: Tier-0/Tier-1 systems, group memberships that drive Okta assignments
- Okta may provision: Tier-2 SaaS with simple entitlements (bounded, documented exception)
This blueprint documents how to integrate these platforms without stepping on each other.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Provisioning owner for Okta | SailPoint / Okta self-managed | SailPoint provisions Okta accounts and group memberships | Okta as a target, not a provisioning engine |
| Provisioning to SaaS apps | Okta / SailPoint / Both (tiered) | SailPoint for Tier-0/Tier-1; bounded Okta for Tier-2 | Document boundary explicitly; avoid overlap |
| Group governance | Okta / SailPoint | SailPoint governs group membership; Okta consumes for app assignment | Groups are the integration point |
| Approval workflows | Okta Workflows / SailPoint | SailPoint for all approval workflows | Single approval source for audit |
| User creation source | HR → Okta / HR → SailPoint | HR → SailPoint → Okta | SailPoint is IGA; Okta is IdP |
| Deprovisioning | Okta-triggered / SailPoint-triggered | SailPoint triggers; Okta revokes sessions | Both must act; SailPoint is authoritative |
| Password management | Okta / SailPoint / Directory | Okta (via directory or Okta-managed) | Okta is the authn layer |
Architecture & Reference Patterns
Pattern 1: SailPoint as Governance Hub (Recommended)
Diagram
Pattern 2: Group-Based Integration
Diagram
Integration Boundary Matrix
| Function | Owner | Notes |
|---|---|---|
| Identity creation | SailPoint (from HR) | SailPoint creates identity; provisions to Okta |
| Okta account provisioning | SailPoint | Via SCIM or Okta API |
| Okta group membership | SailPoint | Groups are the control point |
| App assignment rules | Okta (consuming SailPoint groups) | Okta rules reference SailPoint-managed groups |
| Direct SaaS provisioning (Tier-2) | Okta (bounded exception) | Only for simple SaaS; documented |
| SSO federation | Okta | Okta is the IdP |
| MFA policy | Okta | Okta enforces authn policy |
| Access requests | SailPoint | All requests through SailPoint |
| Approvals | SailPoint | Single approval workflow system |
| Certifications | SailPoint | SailPoint certifies all access |
| Session revocation | Okta (triggered by SailPoint) | SailPoint disables; Okta revokes session |
| Audit evidence | Both → SIEM | Correlated in SIEM |
Provisioning Flow
Diagram
Implementation Approach
Phase 0: Discovery (2-3 weeks)
Inputs: Current Okta config, current SailPoint config, app inventory Activities:
- Inventory current provisioning flows (who provisions what today)
- Document current group governance (who manages Okta groups)
- Identify overlapping provisioning (apps provisioned by both)
- Assess Okta Lifecycle Management usage
- Map approval workflows in both systems
Outputs: Current-state integration map, overlap analysis, gap assessment
Phase 1: Boundary Design (2-3 weeks)
Inputs: Discovery outputs, business requirements Activities:
- Define provisioning ownership per app tier
- Define group governance model (SailPoint manages, Okta consumes)
- Define approval workflow consolidation (move to SailPoint)
- Design deprovisioning flow (SailPoint triggers, Okta revokes)
- Document exceptions and rationale
Outputs: Integration boundary document, responsibility matrix
Phase 2: Integration Build (4-6 weeks)
Inputs: Boundary design, API access Activities:
- Configure SailPoint → Okta SCIM connector
- Configure group synchronization
- Migrate Okta-native provisioning to SailPoint (for Tier-0/Tier-1)
- Configure Okta app assignment rules to use SailPoint-managed groups
- Build deprovisioning workflow (disable + session revoke)
- Configure audit forwarding to SIEM
Outputs: Integrated platforms, migrated provisioning
Phase 3: Validation & Rollout (3-4 weeks)
Inputs: Integrated platforms, test users Activities:
- Test end-to-end lifecycle (hire, role change, termination)
- Test access request and approval flow
- Test deprovisioning and session revocation timing
- Validate audit evidence trail
- Pilot with limited population
Outputs: Validated integration, pilot results
Phase 4: Operate (Ongoing)
Activities:
- Monitor provisioning success rates
- Review boundary exceptions quarterly
- Update integration as apps are added/removed
- Maintain documentation as platforms evolve
Deliverables
- Integration boundary matrix — who owns what, with rationale
- Provisioning runbooks — per-app provisioning procedures
- Group governance model — how groups are managed and consumed
- Deprovisioning workflow — disable, revoke, verify sequence
- Exception process — how to request and document exceptions
- Audit correlation guide — how to trace access across systems
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Dueling provisioning | H | H | Same app provisioned by both; drift | Clear boundary; technical enforcement |
| Group sync failures | M | H | Access not granted/removed | Monitoring; retry logic; alerting |
| Session not revoked on termination | M | H | Terminated users still authenticated | Explicit session revoke in deprovisioning flow |
| Approval workflow confusion | M | M | Users don't know where to request | Single request portal; user training |
| Boundary creep | M | M | Exceptions become the norm | Quarterly boundary review; executive sponsorship |
| Audit correlation gaps | M | M | Can't trace request to access to usage | Consistent identifiers; SIEM correlation rules |
KPIs / Outcomes
- Provisioning success rate: % of SailPoint → Okta provisioning successful (target: greater than 99%)
- Deprovisioning latency: Time from SailPoint disable to Okta session revoke (target: fewer than 15 minutes)
- Boundary compliance: % of apps following defined provisioning ownership (target: 100%)
- Access request cycle time: Time from request to provisioned in Okta (target: fewer than 4 hours for auto-approved)
- Audit completeness: % of access grants traceable from request to provisioning (target: 100%)
Workshop Questions
Security / IAM
- What's the current provisioning overlap between Okta and SailPoint?
- What's the appetite for Okta doing any provisioning vs. SailPoint-only?
- What's the required time-to-revoke when someone is terminated?
IT / Okta Team
- What Okta Lifecycle Management features are currently used?
- What app assignment rules exist and how are groups managed?
- How is session revocation triggered today?
Governance / Compliance
- Where do access requests live today? Is there confusion?
- What audit evidence is required (who requested, who approved, when provisioned)?
- How are certifications handled—Okta or SailPoint?
Requirements Gathering Checklist
- What applications are currently provisioned by Okta vs. SailPoint?
- What's the app tiering (Tier-0, Tier-1, Tier-2) and provisioning ownership per tier?
- How are Okta groups managed today (manually, rules, external)?
- What approval workflows exist in Okta vs. SailPoint?
- What's the deprovisioning flow—does SailPoint trigger Okta session revocation?
- What's the required time-to-provision and time-to-revoke SLAs?
- What audit evidence is required for compliance?
- What exceptions to the boundary exist and why?
- How will the integration be monitored for failures?
- What's the escalation path when provisioning fails?
- How will users request access—single portal or multiple?
- What training is needed for users and admins?