We are hosting IIS ARR in a webapp running as a basic reverse proxy. This is working well and is really easy to configure (unlike the alternative we considered, Azure Application Gateway).
Our proxy takes an incoming url and simply forwards it to a different server so nothing too complicated.
What we need to do now though is to add a url rewrite rule for a tenanted endpoint, so with a url like this:
https://proxy/[customerid]/stuff?id=1
for customer A rewrite to
https://tenantservera/[customerid]/stuff?id=1
and for customer B rewrite to
https://tenantservera/[customerid]/stuff?id=1
Customers could be added at any time, and there are a number of these proxy servers deployed worldwide running behind Azure Traffic Manager, so I would prefer to avoid updating the web.config each time we add a new customer if at all possible.
This appears to be possible (though a bit archaic) with a "real" server running IIS as you can write a custom module in .NET 2.0, deploy to server's GAC and then hook it into the pipeline in IIS. This would update the web.config something like this:
<providers>
<provider name="DB" type="DbProvider, Microsoft.Web.Iis.Rewrite.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<settings>
<add key="StoredProcedure" value="GetRewrittenUrl" />
</settings>
</provider>
</providers>
Does anyone know if this, or anything like it, is possible in a web application? We can't install into the GAC AFAIK.
Related
I am attempting to host multiple websites in a single Azure WebApp rather than having multiple web apps each hosting a site. Each of these sites is rather small, but in order to meet the requirements of the SLA with Azure, we need to have the server scaled with more than one instance for our Production environment, thus the reasoning for combining sites.
After researching this topic, I have got the following setup with our Azure account.
Created the proper CNAME DNS records in our zone manager (complete and works).
Setup the Azure WebApp to respond to the subdomains (complete and works).
Setup a virtual directory for the second web application (complete and works)
At this point, both web applications function correctly and both subdomains are pointing at our Azure instance. We now have the following setup:
both www.mydomain.com and app.mydomain.com bring up the root application that I deployed.
going to www.mydomain.com/app2 and app.mydomain.com/app2 bring up the second application that I deployed to the virtual directory
What I would like to achieve:
Going to app.mydomain.com would bring up the application in the virtual directory.
Going to www.mydomain.com would bring up the application at the root of the azure instance.
However, what I cannot figure out is how to map a subdomain to a specific virtual directory. I have tried to update the Site URL to be the subdomain I want the application to respond to, however, the subdomain still brings up whatever I have in the root of the WebApp deployment.
Should I have some HttpHandler that sits in the site root and directs traffic to the proper virtual directory? Is there a setting in the portal that I am missing? Previously, we did this with Web Roles and tinkering with the ServiceDefinition file, but the tool sets for the Azure Web Apps in regards to publishing, integration with Source Control, etc seem to be a bit further along.
The answer posted by RuslanY will work (with some modifications to the rules slightly) however, after understanding more of the Azure portal and Web App configurations, it is not needed to host multiple sites within a single Web App (Its technically multiple web apps all sharing the resource plan you define, such as 2 instances of Standard Level 0 (S0))*.
As of today's Azure service offerings, the following is true. When you create a new Web App, you pecify the "App Service Plan" that the app falls into. If you have an App Service plan, lets say Standard with 2 instances, any Web App you deploy to that App Service plan shares those resources with other web apps in the same service plan, meaning you are not paying additional costs to host the additional web app if it is in the same App Service plan. I had assumed each web app was its own set of resources (it can be, but doesn't have to be). Given this, to accomplish what I need, I simply create a web app for each sub domain and place them all into the same App Service plan. I now am hosting multiple sites, not paying for 2 servers per site (what I wanted to avoid) and I don't have to use URL rewrites or HTTP Handlers.
I hope this write-up helps others understand the structure of the Azure Web Apps a little bit better. The current online documentation, from what I can tell, doesn't make this exactly clear.
This may be possible to do with URL rewrite rule which takes the hostname of the request and rewrites the request URL to start with the subdomain extracted from the hostname:
<system.webServer>
<rewrite>
<rules>
<rule name="Rewrite Subdomain To Directory">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.mydomain\.com$" negate="true" />
<add input="{HTTP_HOST}" pattern="^(.+)\.mydomain.\com$" />
</conditions>
<action type="Rewrite" url="{C:1}/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
To understand the syntax of the rewrite rules you can refer to the IIS.net documentation about URL rewrite module.
I have been able to create a ASP MVC application that authenticates using Office 365 SSO.
I am looking for a way to have Office 365 as a SSO layer before accessing any internal applications (apache) we have on the network.
We have successfully setup a reverse proxy with ARR / URL Rewrite as discussed in this document:
https://confluence.atlassian.com/display/JIRAKB/Integrating+JIRA+with+IIS+using+ARR
The issue I am having is that URL-Rewrite is happening too high up the execution stack and bypassing any modules.
I am looking for some guidance on how to implement a Office 365 authentication layer on IIS for internal non ASP.NET applications that sits behind a firewall.
Any ideas?
I have experience with ARR and WIF. I had to become familiar with how IIS 7.5 handles native vs. managed code. I am assuming you are running your app pool in integrated mode otherwise the rest of this won't be applicable.
It's hard to know due to not knowing all the details on your issue but you could have a configuration issue related to managed vs. native/unmanaged code. ARR is a native http module. It is used in conjunction with the URLRewrite http module to allow content to be served up from a back end web server.
By default IIS does not run managed http modules for any requests processed by a native handler, such as ARR. To configure IIS to run a managed module for content processed by a native handler, such as WIF or other managed .NET code, you must configure IIS to run managed code regardless of the handler. The simplest way to do this is to set the runAllManagedModulesForAllRequests="true" in the system.webServer\modules element. You can also selectively enable individual modules to run by setting the precondition to "" to override the default IIS behavior:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="" />
<add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="" />
</modules>
Regards
This is the case:
Farm with one WFE and one APP-server. WFE hosts all sites, APP-server hosts all SharePoint web services. Names of servers: SPWFE01 and SPAPP01
WFE can connect to internet through proxy.
Web services should be bypassed, thus not called through proxy
Thus, I configured web.config as following:
<system.net>
<defaultProxy>
<proxy usesystemdefaults="false" proxyaddress="http://proxy" bypassonlocal="false" />
<bypasslist>
<add address="spwfe01"/>
<add address="spapp01"/>
<add address="139\.156\..*"/> <!-- IP-address range of Farm -->
<add address="10\.246\..*"/> <!-- backup IP-address range of Farm -->
</bypasslist>
</defaultProxy>
</system.net>
However, I get null reference exceptions when I call the UPA from code behind. When I remove above configuration, everything works as expected. Thus, web service calls are made through proxy, despite of bypasslist.
What am I doing wrong here?
Alright, fixed it by removing usesystemdefaults-attribute...
According to MSDN:
usesystemdefault
Specifies whether to use Internet Explorer proxy settings. If set to true, subsequent attributes will override Internet Explorer proxy settings. The default value is unspecified.
Thus, now it is "unspecified". I have no idea what unspecified is for a boolean value, but it works...
We're developing a new website running in azure. We are currently developing against the local azure dev environment. But now we need to publish and test the site in the real Azure world. But we would like to run in a "closed" environment, where only know users have access, as the site should not go live yet. Any suggestions to accomplish this?
/Rasmus
Windows Azure has something called 'staging mode', see this post: http://sevans.info/2010/10/10/windows-azure-staging-model/
It's very powerful, and exactly what you need as far as I can see.
You could remove the endpoints of your instance configuration, so there will be no forwarding through the load balancer. After that you could use the Remote Desktop to log into your azure instance and test your web application.
Above suggestions are great and I would also like to add two more in this list as well:
Using production deployment and having a dummy index/default page with directory browsing disabled (already set as default) So when someone come you your site there is nothing they will see. And as there is no directory browsing so they can not guess the page*.aspx to visit your site. This will keep your production site running and you can test it from outside.
Removing your instance form Load Balancer while keeping your instance healthy. This will require you to test the Azure Application by RDP to your instance and then launch internally. If you wish to do so here is the Powershell based trick.
You could restrict the IP addresses that are allowed to access your app if you have a static IP address. As per this link: https://azure.microsoft.com/en-us/blog/ip-and-domain-restrictions-for-windows-azure-web-sites/
Developers can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to their websites. With Windows Azure Web Sites developers can enable/disable the feature, as well as customize its behavior, using web.config files located in their website.
Here's the code:
<system.webServer>
<security>
<ipSecurity allowUnlisted="false" denyAction="NotFound">
<add allowed="true" ipAddress="123.456.0.0" subnetMask="255.255.0.0"/>
</ipSecurity>
</security>
</system.webServer>
I need help, I'm new to the WCF world having recently made the transition from SOAP Webservices.
The WCF service works well when I run in from the VS2008 ASP.NET Development Server i.e. Debug Mode. The problem comes when I try to access the service via IIS.
I've setup a website on my local IIS Webserver hosted on port 8082 (http://localhost:8082) and have created a VirtualDirectory (1.0) that points to the physical directory that contains my WCF Service code. The Website is setup to do ASP.NET 2.0.50727. I can get to the landing page and also an assortment of .aspx pages but when I try to access the Service.svc, the browser never gets there and just sits idling.
http://localhost:8082/1.0/Service.svc
My question is what setup am I missing to get the service to work from inside IIS since I already know it works under the development server.
I'm attaching part of my web.config if that would help.
<system.serviceModel>
<services>
<service name="Service1" behaviorConfiguration="Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="" binding="wsHttpBinding" contract="IService1">
<!--
Upon deployment, the following identity element should be removed or replaced to reflect the
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
You talk about RESTful service, yet you're using the wsHttpBinding.... that's not the REST binding - that would be "webHttpBinding".
For the most part, WCF services ARE SOAP-based - any of the bindings except for the webHttpBinding are SOAP endpoints, so your wsHttpBinding endpoint is definitely not RESTful in any way, shape or form. You can communicate with it using e.g. SoapUI or better yet - the WcfTestClient in your Visual Studio folder.
You cannot however expect to get XML shaped data back from it by just browsing to that URL.
Marc
By default IIS 7.0 is not configured
for WCF services, we are going to
configure IIS 7.0 to run WCF services
i will break up the whole procedure in
steps.
http://basitblog.wordpress.com/2010/01/12/deploy-wcf-service-over-iis-7-0/