{"slug":"platform/28-identity-platform","title":"28 — Identity Platform","section":"platform","sectionLabel":"Platform","status":"unclassified","type":"document","path":"platform/28-identity-platform.mdx","bytes":3433,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **EXTRACTED / NOT CANONICAL.** Descope-as-identity-root is superseded. Clerk\n> owns person/workspace identity at the Gateway boundary; IntegrateWise owns\n> tenant and authorization semantics.\n\n> **Extracted from:** IntegrateWise Platform Specification Suite\n> **Region:** third_region\n> **Original line:** 3330\n> **Lines:** 47 | **Chars:** 2,558\n> **Status:** Raw extraction — requires review and canonicalization\n\n28 — Identity Platform\n28.1 Responsibilities\nIdentity, Organizations, Invitations, Teams, SCIM, SAML, Enterprise SSO, MFA, Service Accounts, API Keys.\n28.2 Identity layers\nPerson Identity: email/password, OAuth, SAML, magic-link.\nDescope is the canonical identity and connection authorization authority (inbound person/organization identity and outbound connection authorization where supported). IntegrateWise owns tenant/workspace ownership, connector semantics, connection bindings, capability definitions, governance, routing, and continuity; Descope owns external authorization state and credential/token lifecycle.\nOrganization Identity: SCIM-issued users, federated mapping.\nService Identity: Service Accounts (svc*), API Keys (key*), scoped to workspaces and capabilities.\n28.3 Inputs\nMarketplace OAuth (per existing spec).\nAdmin invites, SCIM provisioning, SAML IdP assertions.\n28.4 Outputs\nusr*, org*, team*, inv*, key\\_ records.\nSession JWTs bound to device fingerprint (14).\nAudit events for every identity operation.\n28.5 Events produced\nIdentityCreated, IdentityUpdated, InvitationSent, InvitationAccepted, InvitationExpired, TeamCreated, TeamMemberAdded, TeamMemberRemoved, SCIMProvisioned, SCIMDeprovisioned, ServiceAccountCreated, APIKeyIssued, APIKeyRevoked, MFAChallengeIssued, MFAVerified, MFAFailed.\n28.6 Events consumed\nMarketplaceInstalled (per existing spec), WorkspaceSwitched, SecurityAlert.\n28.7 APIs\nPOST /identity/invitations, POST /identity/invitations/{inv_id}/accept, POST /identity/scim/sync, POST /identity/saml/acs, POST /identity/mfa/challenge, POST /identity/mfa/verify, POST /identity/service-accounts, POST /identity/api-keys.\n28.8 State transitions\nUser: pending → active → suspended → deleted. Invitation: sent → accepted | expired | revoked. Service Account: active → rotating → retired. API Key: active → rotated → revoked.\n\n28.9 RBAC + ABAC cross-reference\nRBAC tables (per existing spec) bind usr* → role → cap.\nABAC layer (14.6) reads identity attributes: is_service, mfa_verified_within, device_posture, geo_region.\n28.10 SCIM\nEndpoint: /scim/v2/{org*}.\nMappings: SCIM user ↔ usr*; SCIM group ↔ team*.\nProvisioning direction configurable: pull (SCIM → platform) or push (platform → SCIM).\n28.11 SAML / Enterprise SSO\nACS endpoint: /identity/saml/acs.\nStandard attributes mapped: email, name, department, employee_id.\nJIT (Just-In-Time) provisioning gated by governancePosture.sso_provision.\n28.12 MFA\nTOTP, WebAuthn, push (via mobile app).\nRisk-based re-challenge for high-governance capabilities.\n28.13 Service Accounts\nBound to a Team (not an individual) for audit clarity.\nAPI Keys scoped to cap_ids[] and wsp_ids[].\n28.14 Failure handling\nSCIM conflict → preserve newer-side, raise admin alert.\nSAML assertion replay → reject + alert.\nMFA failure > N → soft lock + admin notify.\n28.15 Extension points\nNew identity provider via IDENTITY_PROVIDER(name).\nCustom ABAC rules via POLICY_PACK(name) (14).\n"}