This document explores multiple feasible and industry-validated approaches to integrate Single Sign-On (SSO) between a parent company (ParentComp using Okta) and a subsidiary (SubComp using JumpCloud). The key requirement is:
Employees of ParentComp must be able to access SubComp-managed apps without creating accounts in JumpCloud. They must continue using Okta as their Identity Provider (IdP).
SubComp employees should continue using JumpCloud as their IdP.
✅ Approach 1: SAML Federation (JumpCloud trusts Okta as IdP)
🔧 How It Works:
- JumpCloud is configured as a SAML Service Provider (SP).
- Okta acts as the Identity Provider (IdP) for ParentComp.
- JumpCloud delegates auth to Okta when a ParentComp user accesses a resource.
✅ Pros:
- Standards-based and secure (SAML 2.0).
- Keeps ParentComp and SubComp identity stacks separate.
- Minimal friction for users (SSO).
❌ Cons:
- Requires JIT provisioning or user mapping.
- JIT creates users at login but doesn’t allow for pre-configuration.
- Manual or programmatic mapping still required inside JumpCloud.
🔍 Real-world Viability:
Yes – This is a common enterprise federation pattern. Validated in multi-org SAML setups.
✅ Approach 2: SCIM Provisioning + SAML Federation (Best for Lifecycle Management)
🔧 How It Works:
- Okta provisions users into JumpCloud via SCIM.
- JumpCloud still delegates authentication to Okta via SAML.
- Ensures users exist in JumpCloud before login.
✅ Pros:
- Full user lifecycle management (create, update, delete).
- Roles and groups can be pre-assigned in JumpCloud.
- Cleanest integration path with most control.
❌ Cons:
- Requires SCIM licensing in both Okta and JumpCloud.
- More setup effort upfront.
🔍 Real-world Viability:
Yes – This is used extensively by large organizations integrating multiple IdPs. Supported by both platforms.
✅ Approach 3: Using a Federation Broker (Auth0, AWS Cognito, Keycloak)
🔧 How It Works:
- A broker sits in the middle and federates with both Okta and JumpCloud.
- SubComp apps authenticate users via the broker.
✅ Pros:
- Supports multiple IdPs cleanly.
- Flexible control for complex multi-tenant setups.
❌ Cons:
- Adds a third-party dependency.
- Increased operational complexity.
- Not ideal for simpler two-org setups.
🔍 Real-world Viability:
Yes – Popular with SaaS companies managing tenant-specific IdPs. Overkill for internal integration.
✅ Approach 4: OIDC Federation (Advanced Custom Trust)
🔧 How It Works:
- JumpCloud or its apps support OpenID Connect (OIDC) federation with Okta.
- Token-based trust validation.
✅ Pros:
- Modern identity standard (OIDC).
- Enables fine-grained control over API access.
❌ Cons:
- Not natively supported out of the box for JumpCloud.
- Requires app-level OIDC config or reverse proxies.
🔍 Real-world Viability:
Possible but requires app-level customization. Rare in JumpCloud + Okta direct setups.
❌ Approach 5: Direct Integration to SubComp Apps (Bypassing JumpCloud)
🔧 How It Works:
- SubComp apps are configured to trust Okta directly.
- Each app must determine which IdP to use.
✅ Pros:
- Fastest direct login route.
❌ Cons:
- Bypasses JumpCloud’s policies and access controls.
- Management burden increases drastically per app.
- Duplicates IdP logic and breaks central control.
🔍 Real-world Viability:
Technically feasible, but poor design for long-term control. Not recommended.
❌ Approach 6: Full Migration to Okta (Unified IdP)
🔧 How It Works:
- SubComp migrates to Okta completely.
✅ Pros:
- Centralized identity control.
❌ Cons:
- Violates the requirement to keep JumpCloud for SubComp.
- Involves large migration effort and user disruption.
🔍 Real-world Viability:
Yes – but not aligned with the stated requirement.
✅ Final Recommendation:
Use SAML Federation with SCIM Provisioning between Okta (ParentComp) and JumpCloud (SubComp). This offers the best mix of:
- Seamless SSO
- User lifecycle control
- Role-based access via groups
- Standards-based interoperability
Key Implementation Checklist:
- Confirm JumpCloud supports external SAML IdPs (Yes).
- Enable SCIM provisioning in Okta and JumpCloud.
- Configure SAML attribute mappings and group assignments.
- Test end-to-end login, JIT creation, and policy enforcement.
- Document access policies for ParentComp users in JumpCloud.
This approach allows both companies to retain control over their identity systems while enabling secure cross-access and future scalability.
| Approach | Authentication Flow | User Creation | IdP Used by ParentComp | IdP Used by SubComp | Pros | Cons | Viability |
| 1. SAML Federation | Okta → SAML → JumpCloud | JIT or Manual Mapping | Okta | JumpCloud | Simple SSO with JIT; standards-based | Requires JIT setup; no pre-assignments | ✅ Recommended |
| 2. SCIM + SAML Federation | SCIM (Okta → JumpCloud) + SAML Login | SCIM Provisioning | Okta | JumpCloud | Full lifecycle + clean SSO | More setup; needs SCIM licenses | ✅ Most Robust |
| 3. Identity Broker | Broker mediates between Okta and JumpCloud | Depends on Broker Setup | Okta (via Broker) | JumpCloud (or Broker) | Multi-IdP support; flexible | Extra infra; complex routing | ⚠️ Complex but Possible |
| 4. OIDC Federation | OIDC token from Okta to App | Manual / API Mapping | Okta | JumpCloud-compatible App | Token-level granularity | Custom app config needed | ⚠️ App-dependent |
| 5. Direct App Integration | Each App trusts Okta directly | None or per-app logic | Okta | Bypassed | Direct path, no intermediary | Bypasses JumpCloud controls | ❌ Not Scalable |
| 6. Full Migration to Okta | JumpCloud users migrated to Okta | Full migration | Okta | Not Used | Centralized identity system | Breaks current JumpCloud usage | ❌ Violates Requirements |