Skip to main content
Enterprise v2.0.0 is built on top of OSS 2.0.0-prerelease3. It inherits both breaking changes from that release: no enterprise-specific breaking changes are introduced on top. This page summarizes the inherited changes and explains how they interact with SCIM-based authentication, which is enterprise-only.

​
Inherited OSS 2.0.0-prerelease3 Breaking Changes

Enterprise v2.0.0 ships with the OSS 2.0.0-prerelease3 base, so both breaking changes from that release apply. See the OSS v2.0.0 Migration Guide for full before/after examples.

​
Note for SCIM Deployments

This is not an additional breaking change: no action is required, and nothing behaves differently for existing SCIM deployments after upgrading. It’s a transparency note about how inherited Breaking Change 2 (above) interacts with SCIM. How SCIM authentication relates to /api/plugins: SCIM’s own inbound provisioning requests (the identity provider calling /scim/v2/* to create/update/deprovision users) authenticate via a separate per-provider bearer “provisioning token,” validated by authorizeSCIMProvisioning(). Those routes are registered with no middleware chain at all: they never touch /api/plugins, and the provisioning token cannot be used to call it. What does change under the hood: when SCIM is enabled, the OSS AuthMiddleware (the component that sets the flag inherited Breaking Change 2 checks for) is never initialized. It’s replaced in the admin-route middleware chain (the same chain that guards /api/plugins) by SCIMController.Middleware(). Because that flag is only ever set by the OSS AuthMiddleware, the createPlugin/updatePlugin auth check from Breaking Change 2 never fires under SCIM: it becomes inert.
This is not currently exploitable. SCIMController.Middleware() is fail-closed on every admin route it guards, including /api/plugins: a missing or invalid session returns 401, and a misconfigured SCIM provider returns 500. There is no “auth disabled” fallback path the way OSS AuthMiddleware has one. An unauthenticated caller cannot reach /api/plugins under SCIM regardless of whether the plugin-specific check fires.
The practical implication: under SCIM, protection for the custom-plugin-path endpoint rests entirely on SCIMController.Middleware()’s own fail-closed behavior, rather than on the layered, defense-in-depth check that non-SCIM deployments get in addition to their own auth middleware. If you rely on SCIM for dashboard authentication, treat SCIMController.Middleware()’s correctness as the sole safeguard for this endpoint rather than assuming the OSS-documented check is also active.