Just-in-time User Provisioning
You set up just in time user provisioning by linking your identity provider to your target app. The system creates a new local account the first time a person logs in. Most teams map group tags from their directory to broad roles inside the app. Broad roles give users too much power once their session starts. How just in time user provisioning works at login This workflow relies on trust between your identity tool and your target system. A user clicks an app icon in their main login portal. T
Just-in-Time Access + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up just in time user provisioning by linking your identity provider to your target app. The system creates a new local account the first time a person logs in. Most teams map group tags from their directory to broad roles inside the app. Broad roles give users too much power once their session starts.
How just in time user provisioning works at login
This workflow relies on trust between your identity tool and your target system. A user clicks an app icon in their main login portal. The identity tool checks the user and builds a signed token. This token holds user details like their email, team name, and job role. The browser sends this signed token straight to the target system.
The target system reads the token and checks the digital signature. It looks up the email address in its own local user list. If the account does not exist, the system makes one right away. It reads the group tags in the token to assign a local role. If the account already exists, the system updates the user role to match. The user lands inside the app without waiting for an admin to make an account.
How to map directory groups to local roles
You start by creating a trust link between the two systems. You copy the public key from your identity provider into the target system. Next, you pick which user fields will travel inside the login token. Most teams send an email address, first name, last name, and group list.
Then you set up role mapping rules inside the target system. Each rule links a directory group name to a local role. For example, a data team group maps to a read role in the database. You should also set a safe default role for unmatched users. Always test the login flow with a test user from each team. Check the local user list to see if the system picks the right role.
Just-in-Time Access + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What account creation solves and what it misses
This setup cuts out manual ticket work for your IT team. Admins do not need to build accounts by hand before people start work. It also stops unused accounts from sitting in apps before a user needs them. Role updates happen at the next login when someone changes teams.
Still, account creation only handles the moment a person logs in. Once the account exists, it stays active inside the target system. If a user leaves the company, this login flow does not delete their local account. More importantly, login checks do not watch what a user does inside the session. A mapped role might let an engineer run any query or command on a server. The login system cannot block a bad query or rewrite card numbers and emails in results.
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 happens when a user leaves the company?
The identity tool blocks the user from starting a new login session. Still, the local account stays in the target system until an admin removes it. Many teams pair login creation with an automated cleanup tool to delete old accounts.
Can this workflow update user roles when people switch teams?
Yes, the target system can update roles on the next login. You must tell the target app to check group tags every time a user logs in. If you turn this off, the user keeps their very first role forever.
Does this setup work for databases and servers?
Some cloud databases and Linux tools support token login and automatic user creation. Many older databases still need static users and local role grants. Teams often map whole groups to shared database roles, which creates broad permissions.