expose Tailscale App Capabilities (grants) using caddy.Replacer

Caddy has the concept of placeholders that allow injecting dynamic values in the Caddy configuration. These can come from a variety of sources such as environment variables, file contents, HTTP Request data, etc. caddy-tailscale currently populates various user data in the http.auth.user placeholder object.

One key thing that we don't currently expose is application capabilities. This is application-specific data that is defined in the Tailscale policy file, and then passed along to the application to interpret and use. We should make this available to pass along to applications as well as for using it in Caddy CEL expressesions.

So, for example, given the following grant in a Tailscale policy file:

{
  "src": "autogroup:admins",
  "dst": "tag:caddy",
  "app": {
    "example.com/app": [
      { "admin": true },
    ],
  },
}

You could theoretically use that in a Caddyfile with something like:

  handle /admin {
    @admin `{tailscale.grants["example.com/app"].admin} == true`
    respond @admin `Hello admin, {{placeholder "http.auth.user.id"}}`
    respond "not authorized" 401
  }

or just pass it along to the backend appplication:

header_up X-Tailscale-Grants {tailscale.grants}

A good example of hooking into the placeholder replacer system can be seen in https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/replacer.go. Because the application grant itself is opaque, if we want to allow exposing it all then we can't do simple prefix matching like caddyhttp. We might have to bring in a full JSONPath library to evaluate the placeholder.

Start with the authentication provider's existing http.auth.user placeholder population and read caddyhttp/replacer.go for the caddy.Replacer integration example. Determine how opaque application grants should be addressed for placeholders and Caddy CEL expressions, then verify that grant data can be exposed to applications and evaluated in the example Caddyfile patterns.