stacklok / toolhive / 24513049502

66%

Build Type

push

github

Committed by web-flow

Commit Message

Store serverName on Cedar Authorizer (#4861)

The AuthorizerFactory interface already passes serverName to
CreateAuthorizer, but the Cedar implementation discarded it. Store it
on the Authorizer struct so downstream enterprise features (#4769,
behavior is identical to today.

The serverName becomes the MCP parent on resource entities (added by
policies like "resource in MCP::<server>". Per the authorization RFC,
this prevents a deny rule compiled from one server's policy from
silently affecting same-named tools on other servers when the
enterprise controller merges policies into a single set.

E2E tested in a Kind cluster with real Okta tokens. The key test
deploys two MCPServers that share a single Cedar ConfigMap -- the
same setup the enterprise controller will produce when it compiles
policies from multiple CRDs into one set.

  Shared Cedar policy set:
    permit(principal in THVGroup::"engineering",
           action, resource in MCP::"<server-a>");
    permit(principal in THVGroup::"engineering",
           action, resource in MCP::"<server-b>");
    forbid(principal, action == Action::"call_tool",
           resource == Tool::"echo")
      when { resource in MCP::"<server-b>" };

  Okta JWT: { "groups": ["Everyone", "engineering"],
              "sub": "jakub@stacklok.com" }

The same user calling the same tool ("echo") gets allowed on server-a
and 403'd on server-b. The only difference is the serverName stored
on each authorizer, which determines the MCP parent on the resource
entity. Cedar's diagnostic log confirms the forbid fires only where
scoped and does not bleed across servers.

Closes #4764

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Coverage Stats

4 of 4 new or added lines in 1 file covered. (100.0%)

11 existing lines in 3 files now uncovered.

57432 of 86855 relevant lines covered (66.12%)

62.14 hits per line