SAML JIT Provisioning
You set up saml jit provisioning by linking your identity provider to your target system. When a user logs in, the target reads the assertion and creates a local account. Teams use this method to skip manual account creation for new hires. The identity provider sends user traits like email, name, and group names during login. Still, teams often map broad groups to powerful admin roles in the target system. When a role is too broad, every group member gets full write permissions right away. Ho
SAML 2.0 + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up saml jit provisioning by linking your identity provider to your target system. When a user logs in, the target reads the assertion and creates a local account.
Teams use this method to skip manual account creation for new hires. The identity provider sends user traits like email, name, and group names during login. Still, teams often map broad groups to powerful admin roles in the target system. When a role is too broad, every group member gets full write permissions right away.
How saml jit provisioning works at login
The workflow starts when an engineer tries to log in to a system. The target tool redirects the browser to the central identity provider. The user enters their main work credentials and completes a second factor check.
Next, the identity provider builds a signed XML response called an assertion. This file holds the user email, display name, and group memberships. The browser sends this signed message back to the target system.
The target system checks the digital signature against a trusted public key. If the signature matches, the tool looks for an existing local user account. If no account exists, the tool creates one on the spot.
During this step, the system also reads the group claims in the file. It matches those group names to local roles inside the database or cloud console. The user lands inside the app with the permissions tied to those local roles.
How role mapping updates user permissions
Some systems only run this account setup on the very first login. Other tools update the user profile and role bindings on every single sign-in. Teams must check how their specific target handles role updates over time.
SAML 2.0 + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If a tool updates roles at login, group changes take effect on the next sign-in. An admin can move an engineer from a read group to a write group. The next time the engineer logs in, the assertion carries the new group name. The target tool reads the change and grants the higher local role.
Still, this flow only pushes data forward during an active login event. If an admin removes a user from the identity provider, the target does not know. The local account stays active in the target system until someone deletes it. Active sessions also keeps the session active until their local timer runs out.
What login setup solves and what it misses
This login flow removes the need to build accounts by hand before day one. It also lets teams manage basic role assignments from one central directory. You do not need to write custom sync scripts just to let people log in.
Yet this setup only decides who gets through the front door at login time. Once the session starts, the target only checks the broad local role. It cannot inspect individual SQL statements, shell commands, or API calls in flight.
A developer with a database role can still run a drop table command by mistake. A support engineer can still query a table full of raw card numbers or emails. Login assertions also cannot ask a manager to approve one risky command on the spot. To control live actions and rewrite sensitive fields like phone numbers, you need runtime controls.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does saml jit provisioning delete accounts when a user leaves?
No, it only creates or updates accounts when a user logs in. To deactivate accounts right away, you must pair it with SCIM or remove accounts manually.
What happens if group claims do not match a local role?
Most systems either block the login or assign a default guest role with zero permissions. You should set the default role to the lowest possible level to prevent accidental exposure.
Can this login flow protect sensitive data inside database queries?
No, the assertion only sets the initial user role when the session starts. It cannot inspect live queries or mask fields like national IDs and emails in results.