6

We're currently struggling with an issue in our azure environment. In our current setup we have an application gateway connecting to 2 application services.

  • 1 app service is using basic auth. Nothing is wrong here and it works as expected.
  • The second app service is using OAUTH with an external Identity server. When connecting this app service through the gateway all calls result in a 401 Unauthorized error.

Quick sketch of our environment: Azure sketch

We've investigated the calls to the service in azure and saw the following: First a redirect to the gateway with a Good token: enter image description here Secondly the call that results in a 401 error. As you can see this call has no token anymore: enter image description here

If we don't go through the gateway we are able to connect to the service with the same token. When we go through the gateway we get the Unauthorized error.

The application gateway is set as following: A listener and 2 backend pools with a path rule. All calls with /service1/* will go to the first app service, while calls with /service2/* will go to the second.

Does anybody know why authentication fails and how to resolve this? If any more info is required, just ask me Thanks in advance.

Improve this question
6
  • Do you use one of default identity providers or your custom identity solution?
    – Nancy
    Apr 4, 2019 at 1:31
  • @NancyXiong no, The identity provider as well as the second application service is fully created by another department.
    – counterflux
    Apr 4, 2019 at 8:52
  • Do you clarify if web applications are using OpenID Connect grant type? Or how do you get the access token at the first call?
    – Nancy
    Apr 4, 2019 at 8:54
  • We get the token for the first call by contacting the Identity server directly in our DEV environment currently. At this moment only the API is set up behind the gateway. A Web environment isn't set up yet.
    – counterflux
    Apr 4, 2019 at 10:55
  • We are seeing similar issues. App Gateway V2 is blocking the 'Authorization' header but V1 passed it just fine.
    – Ian Mercer
    Aug 10, 2019 at 1:17

2 Answers 2

Reset to default
1

Just had to deal with this and found a way of fixing it. It appears that this is the sequence of events:

  1. AG Get's request
  2. AG Parses request and stores a dictionary containing in part the request headers
  3. AG decides to throw away Authorization header because it's dumb
  4. AG eventually runs rewrite rules
  5. ...
  6. Profit!

So, you do actually have access to the authorization header, you just have to be sneaky about it. What I did was add 2 rewrite rules to get it back:

Priority 99: Set X-Auth-Token to {http_req_authorization}

Priority 100: Set Authorization to {http_req_x_auth_token}

This put the authorization token back in play. Make sure to set the priorities so they're run in this order, otherwise it won't work of course. Note that trying to do a rule that just sets authorization to {http_req_authorization} seems to be treated as a no-op and it's skipped. Hence the temporary X-Auth-Token header I create in there.

Improve this answer
0

Did you enable WAF in Application Gateway?

If yes, can you check what rule is blocking this request by enabling logs?

Once you get an idea, on why it is getting blocked, you can enable exclusions in WAF and that way you can make it work.

Let me know if you have any follow up questions.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.