@checkstack/auth-common 0.8.1 → 0.8.3

package/CHANGELOG.md

@@ -1,5 +1,87 @@
 # @checkstack/auth-common
 
+## 0.8.3
+
+### Patch Changes
+
+- 0626782: Guard the role editor against granting inert (and misleading) permissions to the
+  anonymous role.
+
+  RPC procedures carry two independent axes: `userType` (the hard authentication
+  gate) and `access` rules (authorization). An admin can grant the anonymous role
+  any access rule, but if the procedures needing that rule are `userType:
+"authenticated"`/`"user"`, the grant does nothing - the auth middleware rejects
+  unauthenticated callers BEFORE access rules are checked (so there is no security
+  hole; the grant is simply inert). After anonymous users started seeing
+  permission-gated UI, such a grant would surface as visible-but-broken controls.
+
+  - The backend now computes, from contract metadata, the access rules an anonymous
+    caller can actually use (a rule is "usable" iff at least one `public` procedure
+    requires it) via `pluginManager.getAnonymousUsableAccessRuleIds()`, exposed to
+    plugins through the plugin environment.
+  - `auth.getAccessRules` annotates each rule with `anonymousUsable`.
+  - `auth.updateRole` REFUSES to ADD a non-usable rule to the anonymous role
+    (existing grants are untouched, so no configuration can be wedged). This is a
+    guardrail, not an enforcement change - RPC authorization is unchanged.
+  - The role editor disables non-usable rules (with an explanation) when editing
+    the anonymous role.
+
+  Verified live: `getAccessRules` reports 11 anonymous-usable vs 58 not; granting
+  `incident.incident.manage` to the anonymous role returns HTTP 400 with a clear
+  message.
+
+- 56e7c75: Fix frontend access checks to use FULLY-QUALIFIED access-rule ids, and resolve
+  the anonymous role on the frontend.
+
+  Granted access-rule ids are stored fully-qualified as `{pluginId}.{ruleId}` (e.g.
+  `incident.incident.read`) so two plugins defining the same short rule id never
+  collide. The frontend, however, was checking the UNqualified id (`incident.read`)
+  via `isAccessRuleSatisfied`, so every check failed for any user without the `*`
+  (admin) grant - masked in development because dev-auth grants `*`. This silently
+  broke ALL non-admin frontend gating (route guards, sidebar entries, and
+  `useAccess`-based button/link gating).
+
+  - **`@checkstack/common`**: `AccessRule` now carries a REQUIRED owning `pluginId`;
+    `access()` / `accessPair()` require and stamp it; `isAccessRuleSatisfied`
+    qualifies the rule (`{pluginId}.{id}`, plus the manage->read escalation) and
+    matches ONLY the qualified form. There is intentionally NO unqualified fallback
+    - matching a bare id would let one plugin's grant satisfy another plugin's
+      identically-named rule (a cross-plugin privilege-escalation flaw). Every plugin
+      that defines access rules now passes its own `pluginId`.
+  - **`@checkstack/backend`**: `pluginManager.getAllAccessRules()` no longer strips
+    the `pluginId` field (the rule `id` is already fully-qualified for the DB sync).
+  - **Route guard** (`@checkstack/frontend` / `@checkstack/frontend-api`) now
+    checks the FULL rule object (so it qualifies and escalates), not a bare id.
+  - **Anonymous role on the frontend**: the `accessRules` procedure is now
+    `public`, returning the configurable anonymous role's grants to unauthenticated
+    callers; `useAccessRules` fetches them for guests instead of returning an empty
+    set. So anonymous UI now reflects exactly what the anonymous role is allowed -
+    which an admin can change (`isPublic` is only the seeded default).
+  - Incident / maintenance / SLO detail routes are now read-gated (their read rule
+    is an `isPublic` default, so the anonymous role holds it unless an admin
+    revokes it); their dashboard status signals carry that rule and render as a
+    link only when the viewer may open it.
+
+  **BREAKING (`@checkstack/common`):** `AccessRule.pluginId` is now REQUIRED, and
+  `access()` / `accessPair()` require a `pluginId` option. `isAccessRuleSatisfied`
+  matches ONLY the fully-qualified `{pluginId}.{ruleId}` form - the previous
+  unqualified fallback is removed, because it was a cross-plugin
+  privilege-escalation flaw. Any code constructing an `AccessRule` or calling
+  `access()`/`accessPair()` must supply the owning `pluginId`.
+
+  Verified live against an anonymous caller: read pages resolve (qualified match),
+  manage actions are denied, manage->read escalation and `*` still work.
+
+- Updated dependencies [56e7c75]
+  - @checkstack/common@0.15.0
+
+## 0.8.2
+
+### Patch Changes
+
+- Updated dependencies [1fee9da]
+  - @checkstack/common@0.14.1
+
 ## 0.8.1
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/auth-common",
-  "version": "0.8.1",
+  "version": "0.8.3",
   "license": "Elastic-2.0",
   "type": "module",
   "exports": {
@@ -10,14 +10,14 @@
     }
   },
   "dependencies": {
-    "@checkstack/common": "0.13.0",
+    "@checkstack/common": "0.15.0",
     "@orpc/contract": "^1.14.4",
     "zod": "^4.0.0"
   },
   "devDependencies": {
     "@checkstack/tsconfig": "0.0.7",
     "typescript": "^5.7.2",
-    "@checkstack/scripts": "0.4.0"
+    "@checkstack/scripts": "0.6.1"
   },
   "scripts": {
     "typecheck": "tsgo -b",

package/src/access.ts

@@ -1,4 +1,5 @@
 import { access, accessPair, type AccessRule } from "@checkstack/common";
+import { pluginMetadata } from "./plugin-metadata";
 
 /**
  * Access rules for the Auth plugin.
@@ -11,28 +12,42 @@ export const authAccess = {
    * User management access rules.
    */
   users: {
-    read: access("users", "read", "List all users"),
+    read: access("users", "read", "List all users", {
+      pluginId: pluginMetadata.pluginId,
+    }),
     create: access(
       "users.create",
       "manage",
       "Create new users (credential strategy)",
+      { pluginId: pluginMetadata.pluginId },
     ),
-    manage: access("users", "manage", "Delete users"),
+    manage: access("users", "manage", "Delete users", {
+      pluginId: pluginMetadata.pluginId,
+    }),
   },
 
   /**
    * Role management access rules.
    */
   roles: {
-    read: access("roles", "read", "Read and list roles"),
-    create: access("roles.create", "manage", "Create new roles"),
+    read: access("roles", "read", "Read and list roles", {
+      pluginId: pluginMetadata.pluginId,
+    }),
+    create: access("roles.create", "manage", "Create new roles", {
+      pluginId: pluginMetadata.pluginId,
+    }),
     update: access(
       "roles.update",
       "manage",
       "Update role names and access rules",
+      { pluginId: pluginMetadata.pluginId },
     ),
-    delete: access("roles.delete", "manage", "Delete roles"),
-    manage: access("roles", "manage", "Assign roles to users"),
+    delete: access("roles.delete", "manage", "Delete roles", {
+      pluginId: pluginMetadata.pluginId,
+    }),
+    manage: access("roles", "manage", "Assign roles to users", {
+      pluginId: pluginMetadata.pluginId,
+    }),
   },
 
   /**
@@ -42,6 +57,7 @@ export const authAccess = {
     "strategies",
     "manage",
     "Manage authentication strategies and settings",
+    { pluginId: pluginMetadata.pluginId },
   ),
 
   /**
@@ -51,6 +67,7 @@ export const authAccess = {
     "registration",
     "manage",
     "Manage user registration settings",
+    { pluginId: pluginMetadata.pluginId },
   ),
 
   /**
@@ -60,17 +77,22 @@ export const authAccess = {
     "applications",
     "manage",
     "Create, update, delete, and view external applications",
+    { pluginId: pluginMetadata.pluginId },
   ),
 
   /**
    * Team management access rules.
    */
-  teams: accessPair("teams", {
-    read: { description: "View teams and team memberships" },
-    manage: {
-      description: "Create, delete, and manage all teams and resource access",
+  teams: accessPair(
+    "teams",
+    {
+      read: { description: "View teams and team memberships" },
+      manage: {
+        description: "Create, delete, and manage all teams and resource access",
+      },
     },
-  }),
+    { pluginId: pluginMetadata.pluginId },
+  ),
 };
 
 /**

package/src/rpc-contract.ts

@@ -27,6 +27,13 @@ const RoleDtoSchema = z.object({
 const AccessRuleDtoSchema = z.object({
   id: z.string(),
   description: z.string().optional(),
+  /**
+   * Whether an anonymous caller can actually USE this rule (a `public` procedure
+   * requires it). The role editor uses this to warn/disable granting inert
+   * permissions to the anonymous role. Absent/false => only authenticated
+   * procedures need it, so granting it to the anonymous role has no effect.
+   */
+  anonymousUsable: z.boolean().optional(),
 });
 
 const StrategyDtoSchema = z.object({
@@ -177,9 +184,13 @@ export const authContract = {
   // AUTHENTICATED ENDPOINTS (userType: "authenticated")
   // ==========================================================================
 
+  // Public so ANONYMOUS callers also get their effective rules (the configurable
+  // "anonymous" role's grants), not an empty set. The frontend gates nav/links
+  // on these, so an anonymous visitor must see exactly what the anonymous role
+  // is allowed - which an admin can change.
   accessRules: proc({
     operationType: "query",
-    userType: "authenticated",
+    userType: "public",
     access: [],
   }).output(z.object({ accessRules: z.array(z.string()) })),