Overview
Provisioning is where IAM becomes operational reality: accounts and entitlements must be created, changed, and removed reliably across dozens or hundreds of target systems. Your primary architectural decision is how to integrate each target: SCIM, vendor connectors, custom APIs, or indirect provisioning via directory groups.
Each pattern has different trade-offs in reliability, entitlement depth, implementation effort, and operational ownership. A consultant's job is to choose the simplest pattern that meets requirements—then design it for retries, reconciliation, and sustainable support.
The wrong approach: Treating all apps the same. A Tier-0 financial system needs different integration rigor than a Tier-2 SaaS collaboration tool. A custom app with an undocumented API needs different planning than a SaaS with mature SCIM support.
The right approach: Pattern selection by target characteristics, with clear operational ownership and failure handling for each.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Pattern selection | SCIM / Connector / Custom / Indirect | Risk-tiered: prefer SCIM → Connector → Indirect → Custom | Custom is a last resort |
| Entitlement model | Groups only / App-native roles / Both | Groups as abstraction; app-native for complex entitlements | Groups are simpler; roles have more fidelity |
| Reliability SLO | Near-real-time / Hours / Daily | Tier by risk: Tier-0 near-real-time; Tier-2 daily acceptable | Over-engineering creates brittleness |
| Reconciliation frequency | None / Daily / Weekly / Continuous | Periodic reconciliation catches drift | More frequent = more API load |
| Error handling | Fail fast / Retry with backoff / DLQ + manual | Retry with exponential backoff → DLQ → manual runbook | Every error needs a human path eventually |
| Custom integration ownership | IGA team / App team / Shared | App team owns app-specific logic; IGA team owns patterns | Custom without clear ownership decays |
| Change detection | Full aggregation / Incremental / Webhook | Incremental preferred; full as fallback; webhooks often unreliable | Webhooks miss events and lack replay |
Architecture & Reference Patterns
Pattern 1: SCIM (System for Cross-domain Identity Management)
Diagram
When to use:
- SaaS applications with mature SCIM 2.0 implementation
- Standard lifecycle operations (create, update, disable, delete)
- Group-based entitlements are sufficient
Strengths:
- Standard protocol; interoperable
- Near-real-time provisioning
- Good ecosystem support (most IGA platforms, most modern SaaS)
Weaknesses:
- Semantic variations between implementations (disable vs. delete)
- Limited to SCIM's resource model (Users, Groups)
- No support for app-specific resources (permission sets, projects)
Watch for:
- Test actual SCIM behavior (some implementations are partial)
- Understand disable semantics (soft delete, deactivate, or true delete)
- Group membership limits in some implementations
Pattern 2: Vendor Connector
Diagram
When to use:
- Complex entitlement models (SAP authorizations, AD nested groups, database roles)
- On-premises applications
- Apps requiring vendor-tested, supported integration
- When deeper lifecycle operations are needed (attribute sync, complex roles)
Strengths:
- Deeper entitlement coverage than SCIM
- Vendor tested and supported
- Often handles edge cases (attribute transformation, complex logic)
Weaknesses:
- Connector lifecycle management (updates, compatibility)
- Connector-specific bugs and limitations
- May require Virtual Appliance for on-prem targets
Watch for:
- Connector version compatibility with IGA platform
- Upgrade testing requirements
- Credential management for connector
Pattern 3: Custom API Integration
Diagram
When to use:
- Custom/internal applications with no standard interface
- Apps with proprietary APIs not covered by connectors
- One-off integrations where connector development isn't justified
Strengths:
- Full flexibility to match any API
- Can handle completely custom logic
Weaknesses:
- You own it forever (bugs, updates, credentials, on-call)
- No vendor support
- Becomes technical debt without engineering discipline
Requirements for custom:
- Assigned product owner
- Documented API contracts
- Idempotent operations
- Retry/DLQ handling
- Credential rotation
- Monitoring and alerting
- Test coverage
- Runbooks
Pattern 4: Indirect Provisioning (Directory Groups)
Diagram
When to use:
- Applications that authenticate via directory (AD, LDAP)
- Apps with existing group-based authorization
- Legacy apps without provisioning API
- Reducing direct integrations
Strengths:
- Leverages existing directory infrastructure
- Simple—just manage group membership
- Works for apps without any provisioning interface
Weaknesses:
- Limited to what group membership can express
- Dependent on app's group sync behavior and timing
- Can't provision app-native entitlements
Pattern Selection Matrix
| Criteria | SCIM | Connector | Custom | Indirect |
|---|---|---|---|---|
| Implementation effort | Low | Medium | High | Low |
| Operational overhead | Low | Medium | High | Low |
| Entitlement depth | Medium | High | Any | Low |
| Vendor support | Varies | Yes | No | N/A |
| Real-time capability | Yes | Yes | Depends | No (sync delay) |
| Recommended for | Modern SaaS | Complex/on-prem | Last resort | Legacy/directory-auth |
Implementation Approach
Phase 0: Discovery (2-4 weeks)
Inputs: Application inventory, current provisioning processes Activities:
- Inventory all target applications
- Classify by tier (Tier-0/Tier-1/Tier-2)
- Assess integration interfaces per app (SCIM, API, LDAP, none)
- Document current provisioning method and pain points
- Identify entitlement model per app (groups, roles, permissions)
Outputs: Target inventory with pattern recommendations, integration capability matrix
Phase 1: Pattern Design (2-3 weeks)
Inputs: Discovery outputs, IGA platform capabilities Activities:
- Select pattern per application based on criteria
- Define entitlement model per target (groups vs. roles)
- Design reconciliation strategy per target
- Define error taxonomy and handling
- Assign operational ownership
Outputs: Integration pattern decisions, entitlement mappings, operational ownership matrix
Phase 2: Integration Build (Varies by app count)
Inputs: Pattern decisions, credentials, test environments Activities:
- Configure SCIM connections for SaaS apps
- Deploy and configure vendor connectors
- Build custom integrations (with proper engineering rigor)
- Configure indirect provisioning (directory groups)
- Implement retry logic and error handling
- Configure reconciliation schedules
Outputs: Working integrations, reconciliation jobs, monitoring
Phase 3: Validation & Rollout (3-6 weeks)
Inputs: Built integrations, test data Activities:
- Test provisioning end-to-end per pattern
- Test error scenarios and recovery
- Test reconciliation accuracy
- Validate entitlement mapping
- Pilot with production data
- Train operations team
Outputs: Validated integrations, operational runbooks
Phase 4: Operate (Ongoing)
Activities:
- Monitor provisioning success rates
- Triage and resolve failures
- Manage connector lifecycle (updates, testing)
- Review reconciliation drift
- Update integrations as apps evolve
Deliverables
- Integration pattern matrix — app × pattern × rationale
- Entitlement mapping tables — IGA entitlement → target entitlement
- Reconciliation design — per-target frequency, scope, drift handling
- Error taxonomy — error types, retry policies, escalation
- Operational ownership matrix — who owns what, SLAs, on-call
- Custom integration documentation — API contracts, code, runbooks
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| SCIM semantic mismatch | H | M | Unexpected behavior (disable vs. delete) | Contract testing; vendor clarification |
| Connector breaks after upgrade | M | H | Failures spike after IGA/connector update | Staging environment; upgrade testing |
| Custom integration abandoned | H | H | Backlog grows; no one knows the code | Treat as product; assign owner; document |
| Reconciliation drift undetected | M | M | Manual changes persist | Alerting on drift; regular review |
| Rate limiting on target API | M | M | Provisioning delays; failures | Backoff logic; batch operations; coordination |
| Credential expiration | M | H | Sudden complete failure | Rotation calendar; monitoring; alerts |
KPIs / Outcomes
- Provisioning success rate: % of operations completing successfully (target: greater than 99%)
- Provisioning latency (p95): Time from request to completion (target: varies by tier)
- Reconciliation drift rate: % of accounts with differences (target: fewer than 1%)
- Manual provisioning volume: Operations requiring manual fulfillment (target: declining)
- Time to remediate failures: Average time from failure to resolution (target: fewer than 4 hours)
- Custom integration coverage: % of custom integrations with documentation and ownership (target: 100%)
Workshop Questions
Security / IAM
- What are the highest-risk applications requiring the most reliable provisioning?
- What's the acceptable time-to-provision and time-to-revoke for Tier-0 systems?
- What compliance requirements drive provisioning audit evidence?
Application Owners
- What provisioning interface does your app support (SCIM, API, LDAP, manual)?
- What entitlement model does your app use (users, groups, roles, permissions)?
- Who supports integration failures—IAM team or app team?
Operations / IT
- Who owns connector failures and provisioning backlog today?
- What monitoring exists for provisioning health?
- What's the current reconciliation process for detecting drift?
Requirements Gathering Checklist
- What applications are in scope for automated provisioning?
- What's the risk tier for each application (Tier-0, Tier-1, Tier-2)?
- What provisioning interfaces are available per app (SCIM, API, LDAP, none)?
- What entitlement model does each app use (groups, roles, attributes)?
- What's the SLA for provisioning by tier (time-to-provision, time-to-revoke)?
- What reconciliation frequency is needed per target?
- What's the error handling and escalation process?
- Who owns each integration operationally (IAM team, app team)?
- What credentials are needed and how are they managed?
- What's the change management process for connector/integration updates?
- How will manual provisioning work for apps without automation?
- What monitoring and alerting is required?