Have the ability to hide @RequestMapping endpoints that are meant to be used by forward scheme

[aosorio1]

Sometimes we want to have RequestMappings only to be used internally by the Gateway. For example when we create one fallback endpoint to be used by the HystrixGatewayFilterFactory or by using uri forward:/my-endpoint in another route. Right now even if a route is not declared in the RouteLocator is still reachable if that endpoint is declared by means of @RequestMapping. I think this should be configurable for people who want to have more control on which routes should be exposed in the Gateway and only want to made available the routes that were declared in the Gateway Configuration.

[spencergibb]

I can understand what you mean. We'll talk about possible solutions with the spring security team.

[juangupta]

@aosorio1 can you explain me please how did you to resolver this problem?

[juangupta]

Hi @spencergibb, could you tell me what was the solution for this topic?

[spencergibb]

I suspect something like this is possible with spring security. We'd need to set some kind of token in the ForwardRoutingFilter and then setup spring security to secure the internal only mappings to require a valid token. @rwinch, @jgrandja or @jzheaux does something like this exist in spring security already?

[rwinch]

We do not have any concept of forwarding within Spring Security. To do this, you would need support within Spring WebFlux itself. I believe the currently recommended approach is to use ServerHttpRequest.mutate() and then pass the mutated request through the chain. However, I'm not sure how that works from within a controller.

cc @rstoyanchev

[spencergibb]

@rwinch sorry I wasn't clear. We already have support for forwarding. I was asking about creating a token that can be validated later. Then configuring spring security to validate the token.

[rwinch]

Oops...my mistake. You can use ServerBearerExchangeFilterFunction to extract the token from the current AbstractOAuth2Token and then include it in the request from a WebClient instance. Does that help?

[spencergibb]

I think that is what is missing. There won't necessarily be an existing token. We would need to generate one before forwarding and then verifying on the other side.

[rwinch]

How are you generating the token? Are you generating it using client credentials? If so, you could use ServerOAuth2AuthorizedClientExchangeFilterFunction. This obtains a token for the authorization server (if not found in storage), stores it for later, and then includes it in the request.

[spencergibb]

I'm not yet. There wouldn't be an auth server. This is strictly to protect a @RequestMapping to be requested from anywhere but a local forward. It may be better to chat than a long thread.