JIT Provisioning
Just-In-Time (JIT) provisioning automatically creates user accounts when they first sign in via SSO. No manual user creation needed — users are provisioned on demand.
How JIT Works
When a user signs in via SSO for the first time, SecureCodingHub handles account creation automatically:
What Gets Created
When JIT provisions a new user, the following profile fields are populated:
| Field | Value |
|---|---|
| From SSO response (NameID or email attribute) | |
| Name | From SSO attributes (if available) |
| Role | Learner (default) |
| Auth Method | OIDC or SAML (based on SSO protocol) |
| External SSO ID | Unique identifier from IdP |
| Team | None (can be assigned later, or use SCIM) |
Seat Management
JIT provisioning respects your organization's seat limit (maxSeats). When a new user attempts to sign in via SSO, the system checks whether there are available seats before creating the account.
If all seats are used, the new user will see an error and cannot be provisioned. Admins should monitor seat usage from the dashboard and upgrade their plan if they need more seats.
JIT + SCIM
For full lifecycle management, combine JIT provisioning with SCIM:
| Feature | Purpose |
|---|---|
| JIT | Creates users on first login. Immediate access with no admin action required. |
| SCIM | Syncs user attributes, group/team assignments, and handles deprovisioning from your IdP. |
| JIT + SCIM | JIT creates the user on first access. SCIM keeps user data, teams, and lifecycle in sync going forward. |
Promoting Users
JIT-created users are always assigned the Learner role. JIT does not support creating Org Admin accounts automatically.
To promote a user to Org Admin, an existing admin must navigate to the Users page and manually change the user's role. This is a deliberate security measure to prevent privilege escalation through SSO claims.
JIT provisioning: frequently asked
What does JIT provisioning solve that manual user creation doesn't?
JIT provisioning removes the synchronous admin step between a user being added to the IdP and that user being able to start training. With manual creation, an admin has to invite users by email and approve seats one by one — error-prone at scale. With JIT provisioning, the IdP application assignment is the single source of truth, and the SecureCodingHub account is created on the first SSO login. No email invitations, no duplicate accounts, no waiting room.
JIT vs scheduled user access provisioning — when do I need SCIM?
JIT handles user access provisioning on demand: an account is created the moment the user logs in. SCIM is the scheduled push from the IdP that handles ongoing updates — group membership changes, attribute updates, and deprovisioning. JIT alone is enough if you only need account creation; combine it with SCIM when you need offboarding to flow automatically from your IdP without a SecureCodingHub admin clicking through the Users page.
Where does JIT fit in the identity and access provisioning lifecycle?
In the identity and access provisioning lifecycle, JIT covers the create stage — the moment a new identity needs an account in a downstream application. The earlier stages (identity creation, joiner workflows, group assignment) live in the IdP; the later stages (mover, leaver, deprovisioning) are best served by SCIM. Treating JIT as a complete lifecycle solution is a common mistake; it is the on-ramp, not the whole road.
Is JIT provisioning safe — can a malicious IdP claim escalate privileges?
SecureCodingHub's JIT implementation always provisions new users with the Learner role, regardless of any role claim the IdP emits. Promotion to Org Admin requires explicit action by an existing admin in the SecureCodingHub UI. The design intent is to prevent privilege escalation through manipulated IdP claims — even if an attacker compromises a user's IdP identity, the worst they get through JIT alone is a Learner seat in your tenant.