SAML Auto Provisioning
You set up saml auto provisioning by linking your identity provider to your target app. When a user logs in, the identity provider sends an XML message that creates their account. Teams use this setup so admins do not have to build accounts by hand. Still, teams often map broad group names to strong admin roles inside the target app. That shortcut gives too many people full read and write power on day one. How saml auto provisioning works at login The workflow starts when a team member tries
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 auto provisioning by linking your identity provider to your target app. When a user logs in, the identity provider sends an XML message that creates their account. Teams use this setup so admins do not have to build accounts by hand. Still, teams often map broad group names to strong admin roles inside the target app. That shortcut gives too many people full read and write power on day one.
How saml auto provisioning works at login
The workflow starts when a team member tries to log in to a tool. The tool sends the user to the central identity provider to check their name and password. Once the user passes that check, the identity provider builds a signed SAML assertion. This message holds user details like their email address, full name, and team group names.
The target app reads the signed message and checks the digital key to trust it. If the user does not have a local account yet, the app makes one right away. Next, the app reads the group attributes inside the message to set up local roles. For example, a user in the data group gets a matching database role at login.
On later logins, the target app checks the fresh SAML message for any role changes. If the identity provider shows a new group, the app updates the user role to match. This keeps local account permissions tied to the central directory during each login event.
Where login role mapping falls short
Auto provisioning solves the hard work of creating accounts when new engineers join a team. Admins do not need to waste time setting up local profiles in twenty different places. It also stops password sharing because each person logs in with their own central account.
Still, SAML assertions only run at the exact moment a user logs in. If an admin removes a user from the identity provider, active sessions often keeps the session active. Even worse, SAML cannot revoke a local account until the user tries to log in again. Teams must pair SAML with SCIM if they want to turn off accounts right away.
SAML 2.0 + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Beyond account cleanup, login provisioning only decides who gets inside the door. Once an engineer holds a valid session, SAML does not check what commands they run. A user with a broad database role can still read raw emails or card numbers. They can also run a bad delete query that drops a whole table by mistake. Login checks cannot inspect live SQL queries, mask sensitive fields, or pause risky shell commands.
Why teams need controls during the session
Modern security teams separate account creation from live command control. Let the identity provider prove who the person is and what team they belong to. Then, enforce strict rules on every single query or command while the session runs.
When you check actions in flight, broad login roles become much safer to manage. Engineers can log in fast without holding standing admin power over every production table. Masking rules can rewrite phone numbers and national IDs in query results before they return. High-risk commands can wait for a quick peer check on Slack before they run.
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
What is the difference between SAML auto provisioning and SCIM?
SAML creates or updates a user account only when that person logs in to the app. SCIM works in the background to create, update, and disable accounts without waiting for a login.
Does SAML auto provisioning remove access when an employee leaves?
Blocking a user in the identity provider stops them from starting a new SAML login. Still, it does not kill open sessions or delete the local account inside the target app.
Can SAML attributes control which database tables a user can query?
SAML attributes can map a user to a predefined role inside the target tool at login. The target tool itself must still enforce table rules, and SAML cannot inspect live queries.