oscerd commented on PR #27332: URL: https://github.com/apache/camel/pull/27332#issuecomment-5979815678
Thanks @Croway — all addressed; the High is fixed. **1 (High, fail-open window) — fixed.** The policy is now applied in `AiToolConsumer.prepare()`, before the first `register()` (both the warm-up `registerEarly()` and the `doStart()` paths), so the guard is in place by the time the tool is discoverable. And `getToolProcessor()` now **fails closed**: if a policy is configured but the guarded processor isn't ready, it returns a processor that throws `CamelAuthorizationException` → `AuthorizationDenied`, never the bare route processor. Your reproducer is in as `AiToolAuthorizationPolicyStartupTest` and now passes (denied during the window). **2 (guard runs outside the route) — docs corrected.** You're right: `getProcessor()` is the route's outer processor, so the guard runs in front of the route's unit of work / tracing / error handling. The javadoc and the "Authorizing tool calls" adoc no longer claim "inside the route / visible to tracing"; they now say the guard runs in front of the route, the denial is logged at `WARN` and relayed as `AuthorizationDenied`, and it produces no route span or metric. (I kept the processor wrap rather than a route-model rewrite; emitting a denial event/metric is a reasonable observability follow-up if you'd prefer it.) **3 (openai/spring-ai carry no identity yet) — dependency documented.** The adoc and the PR description now state that `camel-openai` and `camel-spring-ai-chat` build a fresh exchange, so an identity-based policy denies under them until CAMEL-24832 (#27264) lands; `langchain4j-agent` and the MCP server path carry it today. The "relay the refusal" behaviour does hold for all four — it is the identity *propagation* that differs, now called out. **4 (shipped policies can't read the MCP principal) — docs corrected; name/roles as a follow-up.** Dropped the "OPA is a natural policy to plug in here" overstatement. The adoc now says the MCP principal is the raw transport user in `CamelMcpSecurityPrincipal`, that Camel's shipped identity/token policies don't read it yet, and that MCP authorization needs a policy inspecting that property. Also fixed the header-safety point in both the `@UriParam` description and the adoc: authorize on exchange properties or validated tokens only, never on headers (they carry the model's tool arguments; with OPA's default `includeHeaders="*"` those would reach the policy input). Exposing a runtime-neutral `CamelMcpSecurityPrincipalName`/roles (and optionally forwarding the bearer token as `CamelKeycloakAccessToken`) I've left as a follow-up — it's the same mechanism that makes finding 5's cross-runtime policy reuse work. **5 (Spring Boot / Quarkus runtimes) — follow-ups, agreed.** This PR wires the Camel Main / JBang (`VertxMcpServerEngine`) path; the core option and the agent paths behave the same on all runtimes. I'll open follow-ups for `SpringAiMcpServerEngine`, `QuarkusMcpServerEngine`, and the quarkus `CamelAiToolProvider` (which also needs an `AuthorizationDenied` branch so a denial isn't reported to the model as a generic failure) once this settles and the runtimes move to 4.23. Pushed as a new head; the full reactor regen is clean (only the ai-tool catalog + DSL entries change). _Claude Code on behalf of oscerd_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
