Skip to content
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

Authorization header not forwarded when using Eureka Service Discovery #3553

Closed
michaelstievenart opened this issue Jun 24, 2020 · 4 comments · Fixed by kestra-io/kestra#3611
Labels
closed: notabug The issue is not a bug

Comments

@michaelstievenart
Copy link

Steps to Reproduce

  1. Running the Eureka Server
  2. Running a Micronaut service (token propagation is setup)
  3. Running A Spring Boot service/Micronaut service
  4. Running an Auth Server that is generating bearer tokens.

Expected Behaviour

When service A (Micronaut service) makes a request to service B (Spring boot or Micronaut Service) the Token TokenPropagationHttpClientFilter successfully adds the Authorization Header and forward the request to service B using eureka discovery. When request arrives at service B the Authorization header is present.

Actual Behaviour

When service A (Micronaut service) makes a request to service B (Spring boot or Micronaut Service) the Token TokenPropagationHttpClientFilter successfully adds the Authorization Header and forward the request to service B using eureka discovery. When request arrives at service B the Authorization header is missing.

Environment Information

  • Operating System**: Windows
  • Micronaut Version: 2.0.0.M3
  • JDK Version: 12

Example Application

Will post an example application here tomorrow, still putting it together

@michaelstievenart michaelstievenart changed the title Authorization header not forwarded when using Eureka Service Discovery between services Authorization header not forwarded when using Eureka Service Discovery Jun 24, 2020
@michaelstievenart
Copy link
Author

Put the repo together demonstrating issue.
https://github.com/michaelstievenart/micronaut-eureka-service-discovery
I initially found the issue on Micronaut Version: 2.0.0.M3 but I have generated the example repo on 2.0.0.RC2

@graemerocher
Copy link
Contributor

Will investigate thanks

@graemerocher graemerocher added this to the 2.0.1 milestone Jun 25, 2020
@jameskleeh jameskleeh self-assigned this Jun 29, 2020
@jameskleeh jameskleeh added status: awaiting validation Waiting to be validated as a real issue and removed status: awaiting feedback labels Jun 29, 2020
@jameskleeh
Copy link
Contributor

@michaelstievenart This is working as designed as far as I can tell. You have service-id-regex set to eureka, however the service id of the target server is appB, so that doesn't match. Even if I set the uri-regex to .* so the token will be passed through, you have no signature configurations on appB to validate the JWT.

@jameskleeh jameskleeh added closed: notabug The issue is not a bug and removed status: awaiting validation Waiting to be validated as a real issue labels Jun 29, 2020
@jameskleeh jameskleeh removed this from the 2.0.1 milestone Jun 29, 2020
@jameskleeh jameskleeh removed their assignment Jun 29, 2020
@michaelstievenart
Copy link
Author

@jameskleeh Hi I just want to clarify something with you around this.

  1. Apologies you are correct, I forgot to annotate the RSASignatureConfiguration with the service id in APP B.
    I have corrected this, and tested service B individually and it is able to authenticate as expected.
    I also set the service id regex on service A to .*

  2. I set the service id regex to eureka as eureka is the service id returned from the OutgoingHttpRequestProcessorImpl shouldProcessRequest when I attempt to make a request from service A to service B, so far this is the case when I have attempted to make any service request using eureka.

  3. As mentioned I also have corrected for the missing RSASignatureConfiguration in app B.
    From all the internal logging as well as look at the CustomFilter (OncePerRequestHttpServerFilter) which I gave highest precedence, there is no Bearer Token on the request when it arrives at service B.

I am not following how this is expected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed: notabug The issue is not a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants