Scim Rfc 7643
The scim rfc 7643 standard defines the core JSON schema for user and group accounts. Teams use this schema to sync accounts from an identity provider to cloud apps. Engineering teams often set up this sync to manage user roles from one central directory. Still, broad group assignments often grant users far more permissions than their daily work requires. How the scim rfc 7643 schema structures user and group data The System for Cross-domain Identity Management splits its rules across two main
Rfc: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The scim rfc 7643 standard defines the core JSON schema for user and group accounts. Teams use this schema to sync accounts from an identity provider to cloud apps. Engineering teams often set up this sync to manage user roles from one central directory. Still, broad group assignments often grant users far more permissions than their daily work requires.
How the scim rfc 7643 schema structures user and group data
The System for Cross-domain Identity Management splits its rules across two main documents. One spec covers the transport protocol, while scim rfc 7643 defines the core data objects. Every record in this model shares a common set of base attributes. Each object gets a unique identifier, an external directory tag, and metadata timestamps. This structure makes sure that both systems agree on which user record they are updating.
On top of the base fields, the standard defines a core user schema. This schema holds login names, display names, email addresses, and phone numbers. It also includes an active boolean flag that shows if an account can log in. Teams can add an enterprise user extension to store department names, cost centers, and managers. Group objects have a simpler shape with a display name and a list of members. Group members can be individual user records or nested group records.
Mapping directory attributes to target apps
Setting up directory sync starts with matching identity provider fields to target app fields. Admins pick a unique user attribute to link accounts across both systems. When a new hire joins, the identity provider builds a JSON payload using this schema. The target app reads the payload and creates a local account with matching attributes.
Group sync works in a similar way to control role assignments inside the target app. Admins link an identity provider group to a specific role inside the downstream tool. When an engineer joins the database group, the sync updates their target app permissions. When someone leaves the company, the identity provider sets their active flag to false. This update revokes their login account in the target app right away.
Rfc: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory sync solves and the runtime gap it leaves open
Directory sync removes the toil of creating and deleting accounts by hand across dozens of tools. It makes sure that HR changes flow straight to cloud apps without human mistakes. Security teams also gain a clear view of which groups map to which apps. When an auditor asks who holds an account, the central directory has the answer.
Still, provisioning only controls who has an account and what static role they hold. Once a user logs in, directory sync has no control over what they do next. A developer in an admin group can run destructive queries or read production customer records. The schema cannot inspect live database statements or filter out sensitive fields like card numbers. It also cannot ask a manager to approve a single risky command in real time. Syncing accounts solves identity lifecycle management, but it does not govern active sessions in flight.
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
What is the difference between RFC 7643 and RFC 7644?
The first document defines the data schema for users, groups, and enterprise extensions. The second document defines the HTTP protocol rules used to send, update, and search those records.
How does the schema handle custom user attributes?
The spec allows custom extensions through dedicated schema URIs in the JSON payload. Teams register a custom namespace so new fields do not clash with standard core attributes.
Does disabling a user via SCIM end their active database sessions?
Setting the active flag to false stops new logins at the target app level. It does not always drop open network sessions or revoke static database keys already in use.