JIT Provisioning
You set up jit provisioning by linking your identity provider to your target system. When a user logs in, the target reads the identity assertion and creates an account. Teams use this flow to skip manual account creation across databases and cloud tools. Still, broad group rules often grant new accounts far too many permissions from day one. How jit provisioning works at login A user starts by logging in through a central identity provider using SAML or OIDC. The identity provider checks the
User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up jit provisioning by linking your identity provider to your target system. When a user logs in, the target reads the identity assertion and creates an account. Teams use this flow to skip manual account creation across databases and cloud tools. Still, broad group rules often grant new accounts far too many permissions from day one.
How jit provisioning works at login
A user starts by logging in through a central identity provider using SAML or OIDC. The identity provider checks the user and sends a signed token to the target app. That token holds key details like the user email, full name, and group names.
The target system checks the signature on the token against a stored public certificate. Next, it looks for an existing local account that matches the unique user identifier. If no account exists, the target creates a new profile on the spot. It fills in the profile fields using the attributes inside the login token.
Role mapping happens during this exact same login step. Admins set up rules that link identity provider groups to local database or app roles. When the token arrives, the target reads the group list and assigns matching local roles. If a user changes teams, the next login updates their local roles to match.
Why teams pair SCIM with on-demand account setup
On-demand account setup handles new hires well, but it cannot handle offboarding alone. Because the flow only runs at login, leaving the company triggers no update token. A former worker who never logs in again still keeps an active local account. Any long-lived API keys or active sessions tied to that account keeps the session active.
To fix this gap, security teams pair login account creation with SCIM background sync. SCIM sends a direct call to disable the local account when HR removes a user. Meanwhile, the login flow still handles fast role updates whenever active engineers sign in. Together, these two standards keep local user lists clean without manual admin tickets.
User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where login role mapping falls short in production
Creating an account at login only solves the first part of the security puzzle. It decides who gets an account and which static role that account holds. Once the user lands inside a database or server, the identity provider steps away. It cannot see or control what commands the engineer runs during that session.
Most teams map identity groups to broad roles like developer, analyst, or admin. An engineer in the developer group gets full read and write permissions upon login. If that engineer needs to check one record, they still hold permissions to drop tables. A single bad query or script can wipe out production data in seconds.
Static roles also fail to protect sensitive columns inside shared tables. When a user runs a broad select query, the database returns every matching row. Native account creation does not rewrite emails, phone numbers, or card numbers in results. Teams need a way to inspect individual queries and mask sensitive fields in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between jit provisioning and SCIM?
On-demand setup creates or updates an account only when the user logs in. SCIM pushes user updates and account removals in the background without waiting for a login.
What happens when an identity token lacks a mapped group?
Most systems either block the login or assign a default role with zero permissions. Admins should configure a safe fallback role so unmapped users cannot read data.
Does login account creation revoke permissions right away?
No, role changes from the identity provider only apply when the user logs in again. Existing sessions keep their old permissions until the session expires or an admin ends it.