SAML JIT
You set up saml jit by mapping identity attributes to local roles during login. The target app reads a signed assertion and creates the user account right away. Teams use this flow to skip manual account creation across internal tools and databases. Still, broad group mappings often grant engineers permanent admin rights that stay active forever. How saml jit works during login A user starts by trying to log in to a target app or console. The target system redirects the browser to the central
SAML 2.0: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up saml jit by mapping identity attributes to local roles during login. The target app reads a signed assertion and creates the user account right away. Teams use this flow to skip manual account creation across internal tools and databases. Still, broad group mappings often grant engineers permanent admin rights that stay active forever.
How saml jit works during login
A user starts by trying to log in to a target app or console. The target system redirects the browser to the central identity provider. The identity provider checks the user and builds a signed XML response. This response holds attributes like an email address, a user ID, and group names.
The browser sends that signed message back to the target service provider. The service provider checks the cryptographic signature against a trusted public certificate. If the signature is valid, the app looks for an existing local user profile. When no profile exists, the system makes a new account on the spot.
Next, the app reads the group claims inside the assertion to set permissions. Admins map central directory groups to local roles inside the target tool. If the assertion lists a database admin group, the app assigns that local role. The user then lands in an active session without waiting for manual ticket approval.
How teams manage group claims and account lifecycle
Most teams link directory groups to fixed role templates across their systems. A single directory group might map to write permissions in several production tools. Each time a user logs in, the target system can update their local role. If an engineer moves to a new team, the next login updates their profile.
Still, this login flow only runs when a user enters the app. It does not remove accounts when someone leaves the company or switches teams. Old accounts stay inside the target database or console until an admin deletes them. If a tool issues long-lived API keys after login, those keys remain active too.
Teams often add SCIM beside login provisioning to fix this cleanup problem. SCIM pushes delete events when an identity provider disables a central user profile. Without that push channel, admins must run manual checks to find stale local accounts. Even with cleanup in place, mapped roles stay broad to cover rare tasks.
SAML 2.0: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login provisioning solves and what it misses
Login provisioning cuts down the time spent creating accounts in every tool. New hires get the right baseline role the first time they sign in. Security teams also keep password rules and multifactor checks in one central place. Auditors can view the central directory to see who belongs to each group.
Yet this workflow only decides who can open the front door. Once the session starts, the identity provider has no view into user actions. The target system trusts every query or command that matches the assigned role. If a role allows table drops or bulk reads, the user can run them.
Static role mappings also force teams to grant high privileges for emergency fixes. An engineer who needs write rights once a month holds them every day. Login assertions cannot approve single SQL statements or pause risky shell commands in flight. Nor can a login flow rewrite sensitive fields like emails or card numbers in results.
Real security requires controls that work inside the active session itself. Teams need a way to check individual commands and mask sensitive fields like phone numbers. Controlling the login step is useful, but runtime checks protect the actual data.
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 inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
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 approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How does saml jit differ from SCIM?
Login provisioning creates or updates an account only when a user signs in. SCIM runs in the background to push user updates and delete disabled accounts.
Does login provisioning revoke active sessions when a user leaves?
No, it only checks identity attributes at the moment of login. Existing sessions and local API keys stay active until they expire or get revoked.
Can SAML assertions restrict which SQL queries a user runs?
No, assertions only pass user attributes and group names to set a baseline role. They cannot read, block, or approve individual database queries during a session.