feat(scim): Add SCIM /Users endpoints

[xlgmokha]

What kind of change does this PR introduce?

Feature. Add SCIM endpoints for core User schema.

What is the current behavior?

These endpoints do not exist yet.

What is the new behavior?

Adds:

Method	Path	Description
GET	/scim/v2/Users	List / paginate / sort SCIM users
GET	/scim/v2/Users/{id}	Get a specific SCIM user
POST	/scim/v2/Users	Create a new SCIM user
PUT	/scim/v2/Users/{id}	Replace a specific SCIM user
DELETE	/scim/v2/Users/{id}	Delete (soft) a specific SCIM user
GET	/scim/v2/ResourceTypes/{id}	Resource Type endpoint for User resource
GET	/scim/v2/Schemas/{id}	Schema description endpoint for User schema

Additional context

• The /Users endpoints authenticate with a bearer SCIM token. Tokens are stored hashed in the new scim_tokens table, are revocable (revoked_at) and expirable (expires_at), and resolve to an sso_provider_id that scopes every query to a single tenant.
• The new /ResourceTypes/{id} and /Schemas/{id} routes are discovery metadata and are unauthenticated, consistent with the existing /ServiceProviderConfig, /ResourceTypes, and /Schemas endpoints.
• All SCIM routes stay behind the existing requireScimServerEnabled gate.
• New migrations add the scim_users and scim_tokens tables. A user's SCIM payload is stored as a JSONB resource column and deletes are soft using deleted_at.
• PATCH and filtering are not implemented yet. List rejects any filter parameter.

Extracted from #2731

[annabkr]

question: could we break this up for easier review? I find Claude is pretty good at doing that, if it feels tedious to do yourself

[hf]

Looks good, some minor clarifications not blocking from my POV.

[hf]

Shouldn't all of these have omitempty?

[xlgmokha]

Shouldn't all of these have omitempty?

RFC 7643 says:

Unlike other core resources, the "Schema" resource MAY contain a complex object within a sub-attribute, and all attributes are REQUIRED unless otherwise specified.

So I opted to not add the omitempty so that they get the default zero values which would be false for all booleans.

field	required
name	Y
name	Y
type	Y
multiValued	Y
description	Y
required	Y
caseExact	Y
mutability	Y
returned	Y
uniqueness	Y
canonicalValues	N
referenceTypes	N
subAttributes	N

[hf]

How is ?sortBy (without =true) handled here?

[xlgmokha]

How is ?sortBy (without =true) handled here?

I think this will return as a default sort order and then the default sorting will kick in. I'll double check though.

[depthfirst-app]

⚪ Severity: LOW

Each bearer token is resolved here, but this authentication path never records last_used_at. A compromised or leaked token can therefore be used without a last-use signal, preventing operators or automation from identifying active credentials or enforcing inactivity-based revocation.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: Update last_used_at on the scim_tokens row each time a token is successfully authenticated. This requires two coordinated changes:

1. In internal/models/sso.go: Modify FindSSOProviderBySCIMToken to update last_used_at on the matched token row after a successful lookup, e.g. by calling tx.RawQuery("UPDATE scim_tokens SET last_used_at = now() WHERE token_hash = ?", ToSCIMHash(raw)).Exec() before returning. Alternatively, expose a new model helper UpdateSCIMTokenLastUsedAt(tx, tokenHash string) error in scim_token.go that performs this UPDATE.

2. In internal/api/scim/server.go: If a separate helper is introduced, call it from the lookup function immediately after the successful FindSSOProviderBySCIMToken call (line 307), and treat any update error as a warning/log rather than a hard failure so that a transient write error does not block valid requests.

No migration is needed since the last_used_at timestamptz column already exists in the scim_tokens table (migration 20260821010000_add_scim_tokens.up.sql) and the SCIMToken struct already maps it via db:"last_used_at".