Configure Azure endpoint so that it works only for specific urls - azure

My Cloud App has two roles with public endpoint. One of them is on https and second on http. Both of them should be configured to be available on the same TLD, let's say example.com. However though, there's a catch:
Http endpoint should respond only to http://example.com (let's say for now that calls to http://something.example.com can be redirected to https://something.example.com).
Https endpoint on the other hand should work the opposite way: calls without subdomains should be redirected to http://example.com.
Is there an easy way to to this by configuring some redirects in cscfg or something?

Any specific reason why you have 2 cloud web roles, Cant you have a single web role and both these application hosted on the same web role as different applications exposing 80, 443 out. This way you can control the redirection easily.

Related

Azure Application Gateway, Azure App Service and Form Based Authentication

I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)

Redirecting from web app behind Azure application gateway

I have two web apps setup in Azure, and for simplicity let's call them webapp1 and webapp2. They sit behind an application gateway, which is selecting the correct web app based on the subdirectory in the URL.
Here's a basic example of how I've set it up:
www.mydomain.com -> webapp1 (the default route)
www.mydomain.com/app -> webapp2
This is working fine, except for one problem: if webapp2 redirects to the login page, for example, the domain in the URL changes to the azurewebsites.net domain. Instead of redirecting to www.mydomain.com/login, it's going to webapp2.azurewebsites.net/login.
I'm fairly new to Azure application gateway, but I know it injects the x-forwarded-* and x-original-host headers. I assumed the gateway would either alter the redirected url request to correct the domain or the config on the web app would use the x-original-host instead. Neither of these things are happening.
Is there a way to configure either the web app or the gateway to make sure the host name doesn't change on redirects? Would this scenario work better with a separate web app/VM with a classic IIS reverse proxy setup instead of the application gateway?
Currently Application Gateway would not overwrite the response from the backend. We do inject X-Original-Host and your application should use that to write the redirect URL correctly back to mydomain.
Example to configure URL rewrite on web app can be found here. An example of rewriting default *.azurewebsites.net domain to a custom domain can be found here

Multiple domains on 1 cloud service

I have a app which is a website builder. Lets say the app is on a azure webrole and its domain is called www.myapp.com.
I want to offer a service where users can use their custom domain with my app. So User 1 has a domain called ww.user1.com, user2 has www.user2.com etc. Whenever someone types www.user1.com, I want them to be able to see come to my my app ie www.myapp.com, with the browser still showing www.user1.com. You can assume I have complete access to the DNS and nameservers of these custom domains. I just need to understand how to configure this in azure.
Not really, as it was on SSL binding of multiple custom domains on a single cloud. I was trying to figure out how to have one app on a cloud service where content changes as per custom domain end user has used to navigate to the website. Turns out its easy, all that is required is cname config and listening to host_header on server side aspx page_init –

Azure CDN for cloud service requests are forwarded to <myapp>.cloudapp.net instead of my custom hostname binding

As mentioned in the title above I have a cloudservice with a WebRole that runs a web app www.myappname.com. I have taken all necessary steps to enable serving of CDN content from my app using url rewrite module on IIS. This works fine but:
The requests coming in from CDN are forwarded to .cloudapp.net instead of my custom hostname binding. I cannot find any place to change this in my configuration. When I create a new CDN endpoint my options for setting the ORIGIN DOMAIN are limited to my cloud service endpoints
Say I got a custom domain name for my cloud service CDN endpoint (ex. static.appnamecdn.com). What happens when I make request with https? I don't see any place to register the "static.appnamecdn.com" 's ssl certificate. Isn't something like this required?
From the help icon on the Create CDN Endpoint screen (Azure Management Portal) I got my answer to the second point above:
If you choose to enable HTTPS for your CDN endpoint, keep in mind the
following points:
You must use the certificate provided by the CDN. Third party certificates are not supported.
You must use the CDN domain to access content. HTTPS support is not available for custom domain names (CNAMEs) since the CDN does
not support custom certificates at this time.
HTTPS is from the CDN to the client only. Requests from the CDN to the content provider (Storage Account or hosted service) are
still made using HTTP.
Regarding your first question, I don't think that is possible...Azure's CDN unfortunately is somewhat limited in its options.
As to the 2nd, as was said in the other answer, it's not possible to use HTTPS with a custom domain name :/

How to convert multiple web sites hosted on IIS to Azure web sites

I currently have a VPS with another provider. On that VPS, I have IIS running with multiple app pools and web sites. I would like to get out of the "server management business", so it would seem that Azure Web Sites (Reserved) would be a great fit. I'm able to get the Azure Web Sites set up, including the custom domain piece. The problem that I can't seem to figure out is how to get the same URLs and behavior that I currently have on my VPS.
For example, I have URLs that look like this right now:
www.foo.com/bar
www.foo.com/baz
wildcard.foo.com/bla
I can't find a way to mimic that in Azure.
Things I've thought of/tried:
Go with one Azure Web Site and have separate virtual directories/app pools in Azure, but googling tells me that isn't supported.
Create 3 Azure Web Sites, one for each of the above. The problem there as I see it is I would need to change to use bar.foo.com, baz.foo.com, and bla.foo.com/wildcard (i.e. lose wildcard subdomain mapping and rework things to have a custom route at the end).
Maybe have one Azure Web Site with a rewrite URL? The problem I think I'd run into there is that it all runs in one app pool, so deploying one piece will affect all 3, and obviously a fault in one app would impact the other 2.
Has anyone else gone down this path and solved it? If the answer is spin up a virtual server, I'll probably just stay where I'm at.
Considering www.foo.com/bar, www.foo.com/baz and wildcard.foo.com/bla are 3 independent web applications that share a domain (foo.com):
Create a Windows Azure Website for each web application. You don't necessarily need to assign custom domain names to them.
Create another, separate website and assign to it the *.foo.com domain using an A record. Refer to Configuring a custom domain name for a Windows Azure web site for instructions. As documented, "With an A record, you map a domain (e.g., contoso.com or www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure web site. The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., www.contoso.com)."
In this "master" website, set up URL redirection (possibly with status code 307 Temporary Redirect) so that requests go to the appropriate applications.
Alternatively, to avoid the delay of the additional request caused by the redirection, set up the "master" website as a reverse proxy that transparently forwards the request to the "inner" web application and sends the response back to the user.
As yet another alternative, use a custom DNS service to do the routing at the DNS layer.
This way, each web application is independent and you solve the issue of routing requests to the appropriate application.

Resources