Skip to content

Authentication & User Provisioning — Architecture Diagrams

Data Catalog Platform // Auth0 + IdP + SCIM

01 — Architecture Overview
02 — SCIM Native Flow
03 — Script Sync Flow
04 — Group Mapping
CUSTOMER ZONE AUTH LAYER DATA CATALOG PLATFORM Identity Provider MS Entra / Okta / Google WS Manages users & groups Issues SAML assertions / OIDC tokens End Users Browser / App login User Provisioning SCIM (native, if supported) or Custom Sync Script Users + group membership sync with group mapping applied Auth0 Authentication delegation layer SAML v2 / OIDC Data Catalog SaaS Platform Permissions managed internally via Groups (not Auth0) SCIM API Users — Group membership Platform Groups Defined inside the Catalog only Not mirrored from IdP Require explicit group mapping SAML / OIDC JWT token login request SCIM API calls creates assigns Auth0 handles only authentication. Permissions live in the Catalog.
Authentication path (Auth0)
Provisioning path (SCIM)
Permissions / Groups (Catalog only)
Identity Provider
Two independent concerns: Authentication (who you are) is delegated to Auth0 and the IdP via SAML or OIDC. Authorization (what you can access) is managed exclusively inside the Data Catalog through Groups. SCIM provisioning keeps users and group memberships in sync — it is not involved in authentication.
Identity Provider SCIM Client (IdP-side) Catalog SCIM API Catalog (Users + Groups) USER CREATION User created / updated in IdP directory SCIM event triggered by IdP automation POST /Users Create or update user User record created in Catalog GROUP ASSIGNMENT Group assigned to user in IdP (IdP group notation) Apply group mapping IdP group name -> Catalog group name PATCH /Groups/{id} Add member to Catalog group User added to group Permissions apply access granted in Catalog DEPROVISIONING User removed from IdP or account disabled SCIM deprovision event triggered automatically DELETE /Users/{id} Delete user User deactivated All access removed immediately REQUIRED CONFIGURATION Configure in IdP SCIM settings SCIM endpoint URL -> provided by Catalog Admin Catalog API Key -> generated in Catalog Group mapping rules -> co-defined by both teams Attribute mapping -> email, name, display_name API Key is used as the Bearer Token value in HTTP calls Catalog Admin responsibilities Generate Catalog API Key for SCIM Create target groups in Catalog Validate provisioning in audit logs No custom code required Rotate API Key on schedule
When to use this flow: The IdP natively supports SCIM provisioning (MS Entra, Okta, OneLogin, Ping Identity...). Configuration is done entirely on the IdP side. No custom development is needed. This is the preferred approach when available.
Non-SCIM IdP — Custom Synchronization Script Scheduler cron / CI / Azure Fn Sync Script Python / Node.js / PowerShell 1. Fetch users from IdP via IdP REST API or LDAP -> email, name, status 2. Fetch groups from IdP with user memberships -> groupId, members[] 3. Apply group mapping IdP group A -> Catalog group X from mapping config file 4. Diff with previous state Determine what changed since last run Option A — Live query GET /Users + GET /Groups from Catalog SCIM API Option B — Local snapshot Read last saved state file JSON / DB on script host 5. Push delta to Catalog POST / PATCH / DELETE via Catalog SCIM API IdP API or LDAP read-only access Local State JSON / SQLite on script host updated each run Catalog SCIM API GET /Users Option A: diff source not used in Option B GET /Groups Option A: diff source not used in Option B POST /Users create new user PATCH /Users/{id} update user attributes PATCH /Groups/{id} add / remove members DELETE /Users/{id} deprovision user Catalog Data store Users list (opt. A) Groups list (opt. A) Created Updated Members updated Deprovisioned opt. B: save state after successful run Script requires two sets of credentials IdP API key / service account (read-only, from IT team) Catalog API Key (SCIM) (from Catalog Admin) -- used as Bearer Token value Group mapping config file (co-designed by both teams) Option B also requires: write access to local state storage on script host
When to use this flow: The IdP does not natively support SCIM provisioning. A sync script acts as the glue layer, scheduled regularly (e.g. every 15-30 minutes).

Diff — Option A (Live query): Each run fetches the current state from the Catalog SCIM API (GET /Users, GET /Groups) and computes the delta against the data just retrieved from the IdP. Simple to implement, always up to date, but adds extra read calls to the Catalog on every execution.

Diff — Option B (Local snapshot): The script saves the last successfully synced state to a local file (JSON or SQLite) on the script host. The next run computes the delta against that snapshot instead of querying the Catalog. Faster and resilient to Catalog API unavailability during the diff phase, but requires managing the lifecycle of the state file (storage, corruption handling, recovery after failed runs).
Group Mapping — IdP Groups to Catalog Groups Groups do not need to match. A mapping configuration defines the correspondence. The group names below are illustrative examples only — actual names depend on each customer's setup. IdP Groups Defined by IT / IAM team data-platform-engineers IT / Data Engineering analysts-finance Finance department analysts-marketing Marketing department data-governance-leads Data governance team it-admins IT administrators Mapping Config JSON / YAML / IdP UI / script config idp_group : catalog_group data-platform-engineers -> catalog-admins analysts-finance -> finance-readers analysts-marketing -> mkt-readers data-governance-leads -> data-stewards it-admins -> catalog-admins Cardinality rules Many-to-one: multiple IdP groups can map to the same Catalog group (data-platform-engineers + it-admins both -> catalog-admins) Catalog Groups Defined by Catalog Admin catalog-admins Full platform access finance-readers Read finance domain mkt-readers Read marketing domain data-stewards Curate + validate assets
Key constraint: Catalog Groups must be created in the platform before any provisioning is configured. The mapping must be documented and agreed upon by both the IT/IAM team (who own the IdP groups) and the Catalog Admin (who controls the Catalog groups and their permissions). Neither team can define the mapping alone.