Skip to content

Support request attributes for HttpRequest/ClientHttpRequest [SPR-16824] #21364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue May 14, 2018 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

Joe Grandja opened SPR-16824 and commented

It would be convenient to provide the capability for setting request attributes that would be accessible via HttpRequest or ClientHttpRequest.

This would allow a ClientHttpRequestInterceptor to be able to access one or more request attributes from the provided HttpRequest.

The 2 types of request attributes would be per-request and shared attributes (used for all requests).

This feature capability would benefit the new OAuth 2.0 Client features currently being built for Spring Security 5.1.

The specific feature being addressed is the client_credentials grant flow with RestTemplate support. This grant flow is implemented as follows:

  1. The OAuth 2.0 Client (RestTemplate) checks to see if it has an Access Token before initiating a protected resource request.
  2. If the Access Token is available, than obtain it via the OAuth2AuthorizedClientService and add the Bearer scheme Authorization header before making the protected resource request.
  3.  If the Access Token is NOT available, than initiate/complete the client_credentials grant flow which results in an Access Token being returned from the Authorization Server. Save the Access Token to the OAuth2AuthorizedClientService and continue with Step 2.

For this OAuth 2.0 Client flow, we have the following request/shared attributes:

Per-request attributes: clientRegistrationId, resourceOwnerPrincipal

Shared (all-requests) attributes: ClientRegistrationRepository, OAuth2AuthorizedClientService

And the flow is implemented with 2x ClientHttpRequestInterceptor:

  1. [OAuth2BearerTokenAuthorizationInterceptor](https://github.com/jgrandja/oauth2-client-demo/blob/master/client-app/src/main/java/org/springframework/security/oauth2/client/web/http/OAuth2BearerTokenAuthorizationInterceptor.java) - sets the Access Token on the Authorization Header using the Bearer authentication scheme
  2. [OAuth2ClientCredentialsGrantInterceptor](https://github.com/jgrandja/oauth2-client-demo/blob/master/client-app/src/main/java/org/springframework/security/oauth2/client/web/http/OAuth2ClientCredentialsGrantInterceptor.java) - performs the client_credentials grant flow

With the current implementation of RestTemplate, these 2x ClientHttpRequestInterceptor's need to be created for each request associating the request/shared attributes to each instance. The ideal scenario would be that the implementations would access these request/shared attributes via the passed in HttpRequest.

I have this flow working in a sample with a custom implementation of ClientHttpRequestFactory and the associated ClientHttpRequest.

The implementations are mainly in this package and the user-facing API is in [OAuth2ClientRestTemplateBuilder](https://github.com/jgrandja/oauth2-client-demo/blob/master/client-app/src/main/java/org/springframework/security/oauth2/client/web/http/OAuth2ClientRestTemplateBuilder.java).
The sample uses OAuth2ClientRestTemplateBuilder in [MessagesController](https://github.com/jgrandja/oauth2-client-demo/blob/master/client-app/src/main/java/sample/web/MessagesController.java).

It would be ideal if we can integrate this capability into RestTemplate as it would provide greater flexibility for the OAuth 2.0 Client features we are in the process of building. This would not only be useful for the client_credentials grant but will also be needed for the refresh_token grant.


Affects: 5.1 RC1

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

After some further discussion, I'm resolving this for now, since the initial focus will be on a WebClient based implementation, which is a better fit for server environments, also in line with our recommendation.

@spring-projects-issues spring-projects-issues added status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants