SAML User Provisioning
You set up saml user provisioning by mapping identity provider attributes to target app roles. When a person logs in, the target system reads the assertion and creates an account. Most teams map directory groups to broad admin or read roles during this initial setup. Broad roles give users standing rights to run dangerous commands long after login finishes. How saml user provisioning works in practice SAML is an open standard that lets an identity provider share sign-in data. When a user logs
User Provisioning (SCIM) + SAML 2.0: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up saml user provisioning by mapping identity provider attributes to target app roles. When a person logs in, the target system reads the assertion and creates an account. Most teams map directory groups to broad admin or read roles during this initial setup. Broad roles give users standing rights to run dangerous commands long after login finishes.
How saml user provisioning works in practice
SAML is an open standard that lets an identity provider share sign-in data. When a user logs in, the identity provider sends a signed XML message. That message goes to the service provider, which is the target app or tool. The message contains user details like an email address, a name, and group names.
With saml user provisioning, the target app reads those details right at login time. If the user account does not exist yet, the app creates it right away. If the account already exists, the app updates the user profile and role assignments. Teams often call this workflow on-demand account creation because it runs during login.
Admins set up attribute mappings in both the identity provider and the target app. You pick which fields hold the user email, first name, and team group names. Then you write rules in the target app to match groups to local roles. For example, a database group in your directory might map to an admin role. Every time the user signs in, the app checks the assertion and updates roles.
Syncing user changes and handling offboarding
Login-based provisioning only runs when a user signs in to the target app. It cannot tell the target app when someone leaves the company between logins. If an admin removes a user from the directory, an active session might keeps the session active. Also, the local account in the target app stays active until the next login.
To fix this, many teams pair SAML login with a background sync protocol. The sync protocol pushes account changes and removals as soon as they happen. Still, many internal databases, servers, and cloud tools do not support background sync. For those tools, teams rely on short session times to force fresh SAML checks. When the session expires, the user must log in again to prove their status.
User Provisioning (SCIM) + 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
Setting up SAML solves the problem of manual account creation across many apps. Admins do not need to create local passwords or update spreadsheets for new hires. Users log in with one central identity and get their assigned roles right away. This setup gives security teams one place to check who can log in.
Still, SAML only decides who gets through the front door at login time. Once a user enters a database or server, SAML steps out of the way. It cannot see or control the actual commands or queries the user runs. A developer with a valid role can still run a drop table command. They can also query tables full of raw emails, phone numbers, or card numbers.
Also, directory groups rarely match the exact permissions needed for a single day's task. Teams end up granting wide roles so engineers can fix urgent bugs when needed. Those wide roles stay active all day and create a huge risk for mistakes. True control requires checking every query and command in flight, not just login assertions.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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 deactivate users when they leave the company?
No, standard SAML only sends user data when a person tries to log in. It cannot send a background signal to delete or disable an existing account. You must expire active sessions or pair SAML with an automated directory sync tool.
How do group attributes map to database or server roles?
The identity provider puts the user's directory group names inside the SAML assertion. The target system reads that list of groups during the login flow. It then matches each group name to a local role based on your rules.
Why is login provisioning not enough for production database security?
Login provisioning only checks who the user is at the start of a session. After login, the user has full power to run any query their role allows. It cannot block bad queries or mask emails and card numbers in query results.