B2b Scim Provisioning
To set up b2b scim provisioning, link your identity system to target business apps. This link sends user accounts and group roles over a standard web API. Teams use this setup to create and remove external partner accounts on a schedule. Still, broad group roles often give users far more power than their daily work requires. How b2b scim provisioning works in practice System for Cross-domain Identity Management is an open standard for syncing user data. One company acts as the identity source
User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up b2b scim provisioning, link your identity system to target business apps. This link sends user accounts and group roles over a standard web API. Teams use this setup to create and remove external partner accounts on a schedule. Still, broad group roles often give users far more power than their daily work requires.
How b2b scim provisioning works in practice
System for Cross-domain Identity Management is an open standard for syncing user data. One company acts as the identity source, while the other runs the target app. The source system holds the main list of workers, groups, and job titles. When a new worker joins a partner team, an admin adds them to a group.
The source system then sends a web request to the target app endpoint. That request carries a structured payload with the user email, status, and group name. The target app reads the payload and creates a local account for that person. It also maps the incoming group name to a local role with fixed permissions.
Updates work the exact same way across the trust boundary between both companies. If a worker changes teams, the source system sends a role change request. If a worker leaves the partner company, the source sends a disable signal. The target app turns off the account right away without manual ticket queues.
How teams map partner groups to local roles
Before turning on the sync, admins from both sides must agree on role mappings. The target app needs a clear rule for every incoming group name. Most teams create a few broad roles such as reader, writer, and admin. They map partner engineering groups straight to these preset local roles.
Both sides also share a secret token to secure the provisioning endpoint. The source system attaches this token to every outgoing web request it makes. The target app checks the token before it creates or edits any user record. If the token expires without notice, every new hire or removal sync stops working.
Admins must also decide how to handle user attribute changes over time. Sometimes an email address or department name changes in the partner directory. The target app must match the user by a fixed unique identifier. Without a stable identifier, the sync might create duplicate accounts for the same person.
User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory sync solves and what it misses
Directory sync solves the basic problem of stale accounts across company borders. It stops former partner workers from logging in after their contract ends. It also cuts down the manual hours spent creating logins for outside teams. Security teams get a clean record of who holds an active account.
Yet this setup only decides who gets an account and a static role. It has zero visibility into what an active user does after logging in. A partner engineer with write rights can still run a bad query on production tables. They can also pull sensitive fields like emails, phone numbers, and card numbers.
Static group sync cannot review single database statements or commands in flight. It cannot pause a risky delete command to ask a manager for approval. It also cannot mask national IDs or card numbers in query results. Directory tools manage the front door, not the live actions inside your systems.
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
How does SCIM differ from single sign-on?
Single sign-on checks who a user is when they log in. SCIM creates, updates, and deletes the user account and role before login happens.
What happens when a SCIM sync token expires?
The target app rejects all account updates from the identity system. Existing users keep their current roles, and deactivated users stay active until someone fixes the token.
Does SCIM control what commands a user runs inside a database?
No, it only assigns a high-level group or role to the user account. It does not inspect, log, or filter live queries or commands during a session.