[
https://issues.apache.org/jira/browse/CAMEL-23723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi reassigned CAMEL-23723:
-------------------------------------
Assignee: Luigi De Masi
> Add oauthProfile support to HTTP consumer components
> ----------------------------------------------------
>
> Key: CAMEL-23723
> URL: https://issues.apache.org/jira/browse/CAMEL-23723
> Project: Camel
> Issue Type: Improvement
> Reporter: Luigi De Masi
> Assignee: Luigi De Masi
> Priority: Major
>
> Follow-up to CAMEL-23685.
> CAMEL-23685 adds a public {{OAuthTokenValidationFactory}} SPI and integrates
> incoming Bearer token validation with {{platform-http}} through the
> {{oauthProfile}} endpoint
> option.
> This follow-up should extend the same incoming Bearer token validation model
> to the main HTTP consumer components:
> * {{camel-undertow}}
> * {{camel-netty-http}}
> * {{camel-jetty}}
> * {{camel-servlet}}
> The goal is to let users configure routes such as:
> {code:java}
> undertow:/secure?oauthProfile=myprofile
> netty-http:http://0.0.0.0:8080/secure?oauthProfile=myprofile
> jetty:http://0.0.0.0:8080/secure?oauthProfile=myprofile
> {code}
> The components should reuse the shared {{OAuthTokenValidationFactory}} SPI
> and {{camel.oauth.<profile>.*}} configuration. They should not duplicate JWT,
> JWKS, OIDC discovery,
> or opaque-token introspection logic inside each HTTP component.
> Expected behavior should be consistent with {{{}platform-http{}}}:
> * validate the configured profile at route startup
> * reject missing or invalid Bearer tokens with HTTP 401
> * map validation infrastructure failures to HTTP 503 where appropriate
> * remove the {{Authorization}} header before route processing
> * expose the {{OAuthTokenValidationResult}} as an exchange property
> * keep component-specific code limited to adapting the native HTTP/security
> hook
> REST DSL should work through existing endpoint properties once the underlying
> HTTP consumer supports {{{}oauthProfile{}}}, for example:
> {code:java}
> restConfiguration()
> .component("undertow")
> .host("0.0.0.0")
> .port(8080)
> .endpointProperty("oauthProfile", "myprofile");
> rest("/secure")
> .get()
> .to("direct:secure");
> {code}
> Contract-first REST DSL OpenAPI should use the same model, for example:
> {code:java}
> restConfiguration()
> .component("platform-http")
> .endpointProperty("oauthProfile", "myprofile");
> rest().openApi("petstore-v3.json");
> from("direct:getPetById")
> .to("bean:petService");
> {code}
> For direct {{rest-openapi}} consumer routes, evaluate and document how
> {{oauthProfile}} should be passed through to the selected
> {{RestOpenApiConsumerFactory}} delegate, for
> example:
> {code:java}
> from("rest-openapi:classpath:petstore-v3.json"
> + "?consumerComponentName=platform-http"
> + "&oauthProfile=myprofile")
> .to("direct:openapi");
> {code}
> The documentation should make clear that {{oauthProfile}} is enforced by the
> underlying HTTP consumer component, not by parsing OpenAPI security schemes.
> The selected
> consumer component must support {{{}oauthProfile{}}}.
> {{camel-servlet}} needs special consideration because it usually runs inside
> a container or application framework that may already provide authentication.
> The issue should
> evaluate whether {{camel-servlet}} should:
> * support {{oauthProfile}} directly as a Camel-level fallback
> * delegate to container/framework security only
> * support it only when explicitly enabled
> * document why direct support is not appropriate, if that is the conclusion
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
