0
votes

I have a Azure cloud service (abc.cloudapp.net) which has authentication enforced using OpenId-Connect. Recently I decided to put it behind a Traffic Manager (abc.trafficmanager.net) for maintenance reasons. After reading about how Traffic Manager works on Microsoft docs, my understanding (as per the flow diagram below) was that when someone hits the TM, it will simply do the DNS look-up for my cloud service and return a 302 with the location as abc.cloudapp.net (or IP may be) and then the client follows the redirect. The documentation clearly says so :

The most important point to understand is that Traffic Manager works at the DNS level. Traffic Manager uses DNS to direct clients to specific service endpoints based on the rules of the traffic-routing method. Clients connect to the selected endpoint directly. Traffic Manager is not a proxy or a gateway. Traffic Manager does not see the traffic passing between the client and the service.

enter image description here

But what I am seeing (through Fiddler/Chrome dev-tools) is that TM seems to be hitting the actual cloud service endpoint causing authentication issues as the redirect URL in my cloud service doesn't match the TM URL and so forth.

Is TM supposed to do this? Or am I missing something crucial here. Below is a related thread.

RequireNonce is 'true' (default) but validationContext.Nonce is null in Azure Traffic Manager , OpenIdConnectAuthentication

1

1 Answers

1
votes

Traffic manager operates at DNS level, there is no 302 since it does not operate using HTTP. When a client makes a DNS query for your domain name, traffic manager will send back a DNS reply that the service is over there.

The client will then connect to the Traffic Manager URL/your custom domain using the IP address given by traffic manager.

So the URL the user sees doesn't change, traffic manager just tells them where the service is.