Refactor authorization logic to eliminate wildcard scope forms

[Thushani-Jayasekera]

Purpose

Make the AI Workspace UI reflect the caller's actual permissions, and make the Platform API's
authorization model something a UI can mirror exactly.

Before this change the UI offered every action to every signed-in user: a viewer or subscriber
could open a create form, fill it in, submit, and only then get a 403 from the Platform API.
The role-to-scope table also over-granted (subresource scopes listed alongside a parent :manage
that already covers them), and scope matching supported a :* wildcard form that nothing in the
platform declared or used — a second, undocumented way for a scope to grant an operation.

What changed

1. Authorization: exact scopes only, no wildcard form

ScopeEnforcer (platform-api/internal/middleware/authorization.go) now admits a request only
when a held scope appears verbatim in the matched operation's accepted-scope list. The
scopeSatisfies wildcard-expansion helper is gone, along with its test file.

• Role-to-scope validation rejects * in any segment as malformed at startup, so a wildcard grant
  can no longer be written into role-to-scope-mapping.yaml.
• HasEffectiveScope matches exactly, the same way the enforcer does.
• Breadth still comes from :manage: a resource's :manage scope is listed in its own and its
  subresources' accepted-scope sets in openapi.yaml, which is what makes ap:gateway:manage
  cover ap:gateway:token:create. That is declared per-operation in the spec rather than inferred
  by pattern matching, so the spec remains the single source of truth for what a scope grants.
• No shipped configuration granted a wildcard scope, so this removes a capability rather than
  changing any existing grant. Wildcard support can be reintroduced later if a real need appears.

Docs updated to match: GO-AUTH-019 in .claude/rules/authentication_authorization.md, Rule 4 of
the rest-api-oauth-scopes skill, and the scope-convention header in role-to-scope-mapping.yaml.

2. Role-to-scope mapping and Helm values cleaned up

• Dropped subresource scopes already implied by a parent :manage on the same role (ap_admin no
  longer lists ap:gateway:token:manage, ap:llm_provider:api_key:manage, and so on). A
  subresource scope is now granted only to roles that do not hold the parent :manage.
• ap:api_key:all:manage is kept explicit and commented as an ownership override — it widens
  which users' keys are reachable, not which actions, and is never implied by ap:api_key:read.
• ap_publisher tightened: LLM providers are read-only for a publisher (creating, editing,
  deleting and deploying providers are admin tasks); it keeps ap:secret:manage, which backs the
  upstream auth values on the proxies it configures.
• kubernetes/helm/platform-api-helm-chart/values.yaml kept in sync with the ap_admin entry,
  with the same reasoning documented inline.

3. AI Workspace: permission-aware UI

portals/ai-workspace/src/auth/permissions.ts holds the scope constants (derived from
openapi.yaml's x-required-scopes, ap: prefix) plus checkPermission, surfaced to components
as hasPermission(scope) from the auth provider. checkPermission mirrors the backend: exact
match, own-level :manage, then each ancestor :manage — because those are the scopes each
operation actually lists. ap:api_key:all:manage is excluded from :manage derivation, matching
the one operation in the spec whose accepted-scope list omits its parent.

Actions the user cannot perform are now disabled with a tooltip rather than hidden, so the UI stays
predictable and the boundary is visible. Applied across projects, applications (including API keys
and associations), gateways and gateway policies, REST/MCP/LLM proxies, provider templates, service
providers, and external servers.

Two details worth noting:

• The tooltip (NO_PERMISSION_TOOLTIP) deliberately does not name the missing scope — naming it
  would let a caller probe the authorization model.
• DISABLED_ACTION_SX dims controls rendered as links (component={RouterLink}), since a disabled
  <a> blocks the click but does not pick up the theme's disabled colouring — without it the
  control looks enabled while doing nothing, which reads as a broken button rather than a
  permission boundary.

The UI check is a UX affordance only; the Platform API remains the enforcement point for every
operation.

Verification

• go build ./... and go test ./internal/middleware/... ./internal/server/... in platform-api
  pass. Enforcer and plugin-enforcement tests now assert a wildcard scope grants nothing, and
  role-map validation tests assert * in any segment is rejected.
• tsc --noEmit on portals/ai-workspace reports no new errors from these changes (the repo has
  pre-existing type errors in unrelated files).

[coderabbitai]

📝 Walkthrough

Walkthrough

The change removes wildcard scope authorization. Scope validation rejects wildcard segments, backend checks require exact scope matches, and portal permission checks follow the same rules. Documentation and enforcement tests now describe and verify explicit scopes and :manage behavior.

Changes

Explicit Scope Authorization

Layer / File(s)	Summary
Scope contract and validation .agents/skills/rest-api-oauth-scopes/SKILL.md, .claude/rules/authentication_authorization.md, platform-api/internal/middleware/role_scope_map.go, platform-api/internal/middleware/role_scope_map_test.go, platform-api/resources/role-to-scope-mapping.yaml	Scope guidance and validation now require explicitly named segments. Wildcard scopes are rejected during startup.
Backend exact scope enforcement platform-api/internal/middleware/authorization.go, platform-api/internal/middleware/authorization_test.go, platform-api/internal/middleware/scope_enforcer_test.go, platform-api/internal/server/plugin_scope_enforcement_test.go	Authorization now requires exact scope equality. Wildcard authorization cases and their former matching tests are removed or changed to denial cases.
Portal permission matching portals/ai-workspace/src/auth/permissions.ts	checkPermission removes own-level wildcard authorization and documents exact matching with applicable :manage scopes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• wso2/api-platform#3022: Modifies role scope validation and tests for malformed or wildcard scopes.
• wso2/api-platform#3045: Modifies authorization scope semantics and role-to-scope validation.
• wso2/api-platform#3127: Modifies portal scope matching and :manage inheritance behavior.

Suggested reviewers: renuka-fernando, malinthaprasan, krishanx92

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	⚠️ Warning	The description explains the purpose, implementation, and verification, but it omits most required template sections.	Add the required Goals, User stories, Documentation, Security checks, Samples, Related PRs, and Test environment sections, including issue links and security responses.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the main change: removing wildcard scope forms from authorization logic.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}