[FEATURE] SCIM 2.0 support

[therealbrad]

Feature Summary

Add SCIM 2.0 (System for Cross-domain Identity Management) support to enable
enterprise Identity Providers (Azure AD, Okta, PingFederate, etc.) to
automatically provision, update, and deprovision users and groups in TestPlanIt.

Problem Statement

Enterprise customers provisioning hundreds or thousands of users cannot manage
user accounts manually. When a SAML SSO integration is in place, authentication
is handled — but user lifecycle management (onboarding, role assignment,
offboarding) still requires manual admin intervention in TestPlanIt.

Current Situation

• SAML 2.0 handles authentication and creates users on first login
  (auto-provisioning)
• Groups exist in TestPlanIt with an externalId field designed for directory
  sync, but no automated sync mechanism exists
• Role and group assignments must be managed manually by a TestPlanIt admin
  after the user's first login
• When a user is deprovisioned in the IdP, their TestPlanIt account remains
  active until manually deactivated

Desired Outcome

• Enterprise IdPs can push user and group data to TestPlanIt via standard
  SCIM 2.0 REST endpoints
• Users are created, updated, and deactivated automatically in sync with the
  corporate directory
• Group memberships and TestPlanIt role assignments can be driven from IdP
  group mappings
• Security teams can guarantee that deprovisioned employees lose access
  immediately across all systems including TestPlanIt

Proposed Solution

Implement a SCIM 2.0 compliant REST API layer in TestPlanIt that integrates
with the existing User, Group, and GroupAssignment models.

User Story

As an IT Administrator at an enterprise organization, I want TestPlanIt
to accept SCIM 2.0 provisioning requests from our Identity Provider so that
user onboarding, role assignment, and offboarding are automated and consistent
with our corporate directory without requiring manual intervention in TestPlanIt.

Acceptance Criteria

• SCIM 2.0 /Users endpoint: supports GET (list/filter), POST (create),
  PUT (replace), PATCH (update), DELETE (deprovision)
• SCIM 2.0 /Groups endpoint: supports GET, POST, PUT, PATCH, DELETE with
  member management
• SCIM user attributes map correctly to TestPlanIt User model fields
  (email, name, active status)
• SCIM groups map to TestPlanIt Groups via existing externalId field
• SCIM group membership changes sync to GroupAssignment records
• Configurable mapping from IdP groups to TestPlanIt roles
  (USER, PROJECTADMIN, ADMIN)
• SCIM Bearer token authentication with token management in admin settings
• Deprovisioning a user via SCIM (active: false) immediately revokes
  TestPlanIt access
• All SCIM provisioning events are captured in the AuditLog
• Successfully tested with at least Azure AD and Okta as IdPs

Design Mockups

N/A — SCIM is an API-level integration. Admin UI additions:

• SCIM token management section in SSO/Authentication settings
• Group mapping configuration (IdP group name → TestPlanIt role)

Alternative Solutions

Option 1: LDAP Directory Sync

Build a periodic LDAP sync service that pulls user/group data from corporate
directories on a schedule. Less real-time than SCIM, more complex to configure,
and requires network access from TestPlanIt to the LDAP server. The existing
externalId field on Groups suggests this was considered. Lower priority than
SCIM as most modern IdPs prefer SCIM.

Option 2: Enhanced SAML JIT Provisioning

Extend the existing SAML just-in-time provisioning to map SAML assertion
attributes (group membership, role) to TestPlanIt permissions on every login.
Simpler to implement but does not handle deprovisioning and only syncs on
active login events.

Technical Considerations

Dependencies

• Requires API changes (new /scim/v2/ route namespace)
• Requires database schema changes (SCIM token storage, group mapping config)
• Requires third-party integration (Azure AD, Okta verification)

Performance Impact

SCIM operations are event-driven and low-frequency (provisioning events, not
per-request). Minimal performance impact expected. Bulk import endpoints
should be processed via BullMQ background workers consistent with existing
copy/move architecture.

Security Considerations

• SCIM endpoint must require Bearer token authentication (separate from API
  tokens — SCIM tokens are IdP-specific)
• Token storage should use existing AES-256-GCM encryption pattern for
  integration credentials
• Deprovisioning (active: false) must immediately invalidate all active
  sessions for that user, not just block future logins
• All SCIM events must be written to AuditLog with SCIM_USER_PROVISIONED,
  SCIM_USER_DEPROVISIONED, SCIM_GROUP_SYNCED action types
• SCIM endpoint should have its own rate limiting separate from the main API

Business Value

Priority

• Critical - Core functionality gap
• High - Significant improvement

Affected User Groups

• Test Managers
• QA Engineers
• Developers
• Project Managers
• Stakeholders

Expected Usage

• Occasionally
  (Provisioning events are infrequent but critical — happens on employee
  onboarding/offboarding/team changes, not daily user activity)

Implementation Effort

• Extra Large (>2 weeks)

(SCIM 2.0 spec compliance, IdP testing with Azure AD and Okta, schema changes,
audit integration, session revocation on deprovision)

Related Issues/Features

• Related to SAML SSO implementation
• Related to Groups / externalId directory sync design
• Blocks enterprise deals requiring automated user lifecycle management

Additional Context

This feature is a hard requirement for enterprise customers in regulated
industries (banking, healthcare, government) who cannot manually manage user
accounts at scale. Customers with 1,000+ users and strict offboarding SLAs
(e.g., DORA compliance) will not go to production without it.

The existing data model is well-positioned for this:

• Groups.externalId already anticipates external directory references
• AuditLog infrastructure supports adding new SCIM action types
• UserIntegrationAuth pattern can be extended for SCIM token storage
• BullMQ worker architecture handles async bulk operations

Examples from Other Tools

• TestRail: Supports SCIM via Okta and Azure AD integration
• Xray: Inherits SCIM from Jira/Atlassian Access
• Testmo: Supports SCIM 2.0 with Okta and Azure AD

Checklist

• I have searched for similar feature requests
• I have provided a clear problem statement
• I have described at least one solution
• I have considered alternatives
• This feature aligns with TestPlanIt's goals