SCIM 2.0: Implement discovery endpoints (ServiceProviderConfig, ResourceTypes, per-URI Schemas)

[InterstellarStella]

Summary

Sentry's SCIM 2.0 implementation currently exposes provisioning endpoints (/Users, /Users/{id}, /Groups, /Groups/{id}) and a /Schemas index, but does not implement the SCIM 2.0 service discovery endpoints defined in RFC 7644 §4.

Specifically, the following endpoints return 404:

• GET /scim/v2/ServiceProviderConfig
• GET /scim/v2/ResourceTypes
• GET /scim/v2/Schemas/{schemaUri} (per-URI lookup, e.g. urn:ietf:params:scim:schemas:core:2.0:User)

Reference in code: src/sentry/api/urls.py only registers Users, Users/{id}, Groups, Groups/{id}, and Schemas (index only).

Why this matters

Several Identity Governance and Administration (IGA) platforms run a SCIM 2.0 compliance pre-flight against the target service before allowing an integration to be enabled. These pre-flight validators follow RFC 7644 strictly and require:

1. ServiceProviderConfig to advertise supported features (filter, patch, bulk, sort, etag, auth schemes).
2. ResourceTypes to enumerate supported resources (User, Group).
3. Per-URI /Schemas/{uri} lookups to retrieve attribute definitions for each resource.

When these endpoints return 404, the validator marks the service as not SCIM 2.0 compliant and blocks the integration from being configured, even though the actual provisioning endpoints work correctly against Okta and Microsoft Entra ID (which hardcode the schemas client-side and skip discovery).

Example validator output

Service is not SCIM 2.0 compliant.
- HTTP GET on .../scim/v2/ServiceProviderConfig failed: not found (404).
- HTTP GET on .../scim/v2/ResourceTypes failed: not found (404).
- User is not present in ResourceTypes
- Group/Role/Entitlement is not present in ResourceTypes
- HTTP GET on .../scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:User failed: not found (404).

Proposed solution

Implement the three missing read-only endpoints, scoped per organization under the existing /api/0/organizations/{org_slug_or_id}/scim/v2/ prefix:

1. GET /ServiceProviderConfig returning a static document describing Sentry's actual capabilities (e.g. filter.supported = true with eq only, patch.supported = true, bulk.supported = false, etag.supported = false, bearer token auth scheme).
2. GET /ResourceTypes returning entries for User and Group, mapped to the schema URIs already defined in src/sentry/core/endpoints/scim/constants.py (SCIM_SCHEMA_USER, SCIM_SCHEMA_GROUP).
3. GET /Schemas/{schemaUri} returning the per-URI schema document. The schema definitions already exist in src/sentry/core/endpoints/scim/schemas.py (SCIM_USER_ATTRIBUTES_SCHEMA, SCIM_GROUP_ATTRIBUTES_SCHEMA), so this is largely a routing addition that returns the matching object by id.

All three endpoints are read-only and require no new persistent state, so the implementation cost is relatively low.

Acceptance criteria

• GET /scim/v2/ServiceProviderConfig returns a 200 with a valid SCIM ServiceProviderConfig resource.
• GET /scim/v2/ResourceTypes returns a 200 with User and Group resource type entries.
• GET /scim/v2/Schemas/{schemaUri} returns a 200 for the User and Group core schema URIs and a SCIM-compliant 404 for unknown URIs.
• Documentation updated at https://docs.sentry.io/api/scim/ and https://docs.sentry.io/organization/authentication/sso/ to reflect full SCIM 2.0 discovery support.
• Existing Okta and Entra ID integrations continue to work without changes.

References

• RFC 7644 §4 Service Provider Configuration Endpoints
• RFC 7643 SCIM Core Schema
• Original support conversation: https://app.intercom.com/a/inbox/onh0p2wm/inbox/admin/9850682/conversation/215474146388601?view=List

[linear-code]

ENG-7619

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-settings-auth for triage ⏲️