I have an Asp.net application 3.5. I want to be able to allow multiple/ different clients to access the same application but using different URL's. I have already managed to configure the database to allow this.
So here's the main part.
I want to host my application in a domain say...
wwww.myapplication.com
then allow different client to access the same application using
1) www.clientOne.myapplication.com
2) www.clientTwo.myapplication.com
Also the client subdomains i.e(clientone.myapplication.com and clienttwo.myapplication.com)
should be autocreated by the client upon registration.
How can I achieve this..Your help will be greatly appreciated
A good example of how I want my application to work is
www.quickschools.com
I finally found out the solution that I wanted, so I thought I would share with you my finding. It turns out I needed to create a web application from another running Asp.net web application (From C# Code)
This tutorial by Robbe Morris was really helpful if you need to get started on this.
Another article you might want to check out is this one.
To have different url's using the same application, i would use "301 redirect" subdomains. I'm not really sure how to have a webapp create these subdomains.
I think the way to do this is to make the website the default website on the server i.e. configure so all requests to the servers IP hit this website (unless the header matches another website that explicitly looks for it). You do this just by not specifying a header on the IIS settings (only an IP address and a port number) - you can only do this for one site per IP address/port combination on the server.
Then look at the request url in the website to determine which domain was requested.
This way there is no need to 'create' subdomains... but you do need to reject all request to a domain that you don't want to recognize.
If you can't do this then you would need to adjust the IIS metabase from the application - not impossible - but a very risky and probably a bad idea.
The common case is that you'll have to configure a new virtual site for each of your new tenants during account provisioning. See Creating a New Virtual Server on how to achieve this programatically. Some though argue (with convincing arguments...) that spinning up an appdomain for each tenant is a waste of resources and one should use routing in the application that inspect the HOST header, see Multi-tenant ASP.NET MVC – Introduction.
Configuring IIS/ASP to respond to your tenant sub-dmains is the easy part. The real problem will be to configure DNS for your tenants, and that depends on your DNS solution.
Related
If I pass in some Ids from an Asp.net application to SSRS server to render reports - how do I make sure that Ids are not read/modified by the end user?
One way I guess is to use ReportViewer control in Asp.net app and have SSL implemented, but is that foolproof? or are their better/alternate ways to implement security in such an app.
Three levels you could do for security purposes:
Change the default port on the SSRS server to something other than 80. EG: Change it to 81 and then someone needs to connect via: http:// (servername):81/ReportServer. Using a different port makes traffic not on the common internet port of 80 may be a good way to hide usage. This would also require that on the server hosting this port that you open this port up under Windows Firewall settings for use with this application.
Use the HTTPS with a certificate to determine that connection is valid between a host and target.
Set up only a single user on the SSRS Site aside from a local admin. Give that user read only rights. Set up your application to authenticate to the ReportViewer via remote mode but HARD CODE this value into your method, do not put in an app or web config. This way someone would have to have access to source code to be able to view user, they would not be able to get into the SSRS site to even see the user if they were not a local admin on the server hosting SSRS.
Those are my ideas anyways. Most of the time people have problems with SSRS being too secure to just get in versus yours you want more security. I hope some of this helps as I know that this method I cannot say is 100% foolproof(nothing is IMHO) but it now has added a level of complexity in adding a different port as well as a dedicated user with minimal permission only viewable by one other account but can be hardcoded in front end applications.
You can also add your security to your report level. Use User!UserID to capture who is logging into your report. and check that with a dataset you create from the application database that manages the access rights to the reports. This way, you can filter the data from showing for wrong users.
Note: Please consider this as another layer to your system security and Do not rely only on this. There are ways that a power user can go around this.
Im currently in the process of exposing our internal CRM system to the web so our employees can use it outside out network. The data is being surfaced to our web application via asp.net WebAPI.
We have SSL setup on the website. But am thinking how else I can make sure the WebAPI is secure from malicious use. My ideas are:
Tracking what IP addresses are accessing the WebAPI and only allow addresses that we have validated are from employees. Problem with this having dynamic IP addresses we might be constantly updating a data store of valid IP addresses.
The user has to login to the system. So every request to the webapi will send across their login details which will be validated before the webapi will process any request.
Pass the device ID of the device using the webAPI and validate (pretty much the same as IP Address tracking in idea 1)
Having a unique clientside generated access token which much match up at the server side.
Has anybody got any advice on my security ideas I outlined? Is it to little or is it overkill?
Just want to make sure the data cannot be hacked, because my butt would be on the line if it did.
Thanks in advance
I would actually choose a totally different solution - updating valid dynamic IP's will be hell.
I would:
Create a new Project using the "Intranet Application" instead of using "Internet Application"
Host the application on your local office network
Set up VPN to your Office for your colleagues
Would this solution be possible for you?
I am an C# ASP.NET developer. I am trying to route URL from one domain to another using Godaddy IIS Virtual dedicated server or Dedicated server for ASP.NET.
For example I have a website application for client_A in my server which is intended to be use by multiple clients with different products.
An example URL: www.myserver.com/client_A/product/bear/?productid=1 or using pretty URL www.myserver.com/A_Application/product/bear/1
I would like to setup for my client to point to client_A using his/her domain.
My Client example URL will be: www.hisserver.com/product/bear/?productid=1 or using pretty URL www.hisserver.com/product/bear/1
Thanks!
The simplest solution would be for you client to set up their domain to simply point to your server, then use Apache virtual hosts to point that domain to the directory in question. I'm not sure if godaddy allows multiple virtual hosts like that, so you could also do it with a mod_rewrite based on the incoming Host.
I am working on an ASP.NET MVC web app that allows people to publish content, but other than publish the content to a remote server, I want to allow people to use their domain name directly. For example, the user "Tom" can have his domain name TomSite.com point to http://www.mywebapp.com/user/tom, but the sub path will also be mapped. For example, TomSite.com/path will be mapped to www.mywebapp.com/user/tom/path, and this is transparent to the web visitor. The visitor will never see "mywebapp.com" anywhere on TomSite.com.
I think Smugmug.com provides such service, to allow people to use their own domain name for the photo portfolio. I want to achieve the same result.
How can I do this? Thanks!
This require multiple steps.
First you have to find out how your users will configure their domain to have a CNAME record for you site. You can archieve this in a number of ways where the best is education. Making partnerships with hosting providers requires a great deal of volume.
In IIS this will require you to either add each host name manually (however this could also be archieved through scripting) or have a dedicated IP address only for you site.
There is also a need for the domain to be associated with an account. The user has to add this themselves and you would probably add a check in the interface which confirms the domain is pointed at your server. The code for this would look like (remember to include the System.Net namespace).
if (Dns.GetHostEntry("www.user.example.com").HostName == "www.example.com")
{
// www.user.example.com is a CNAME for www.example.com
}
In you ASP.NET MVC project you need to implement routes for this particular purpose. Create a custom class inheriting from Route which also takes the domain into account.
Smugmug (who you mentioned) get their users to setup a CNAME record that will alias the url for the user's personal photo section. For most users this will probably require them contacting their host or looking up help files in order to get it all setup.
So, while www.tomsite.com could transparently serve up pages hosted at www.mywebapp.com the users will have to put some kind of effort in. To make it a completely seamless you will need some kind of arrangement with the users web host (Smugmug appear to have such an arrangement with GoDaddy).
I doubt you will be able to setup such integration with all the web hosts out there, so the only complete solution would be to host the websites of your users yourself (I do not know enough about your wider situation to determine if that is a reasonable solution).
Note: setting up an alias on your own web server (aka url rewriting) will not work, unless you host their site yourself, as obviously people fetching from your user's domain will not arrive at your server in the first place.
Have each customer's friendlyname pointed at the external ip address of your webserver.
Use IIS to resolve the friendlyname specified in the host header request to the logical website you want delivered to that friendlyname. IIS will happily map both a website and a virtual folder to the same folder in the file system. Create a website for each customer. Then bind that website to the customer's friendlyname.
Remember to map the default website only to your own friendlyname(s). If you leave it in promiscuous mode (mapped to "*") results will be unpredictable.
To set host header mapping
Select Default Web Site under the Sites node. In the Actions pane at top right click on Bindings... to open the Site Bindings dialog. There will be a list of bindings, probably containing a single entry that says http * 80. Select this and click the Edit... button. Set Host name to your own friendlyname.
Run IIS7 Manager and for each customer site create a website under the Sites node. Set both file path and host header binding while you are creating each web site. Obviously the host header binding (host name) should be that customer's friendlyname.
Just make a new record in your webserver setting tomsite.com directly to your mywebapp.com/user/tom/ path ?
See it like an alias :)
Ofcourse, since you're asp.net/windows based, i think you'll have to digg deep into IIS to automate this kind of stuff. If you were on apache it would be adding 3 simple lines to httpd.conf.
I have a Web Service (ASMX) with a few Web methods on our production Web server. On a separate internal Web server (which isn't publicly exposed) I have another Web site that will use the ASMX's public web methods. What are some of the best ways to secure the Web service such that only the internal Web server can access the Web Services running on the publicly exposed Web server?
One of the easiest ways is to pass credentials in the soap header of the message. So each call passes along the info needed to determine if the user is authorized. WSE makes some of that easier but one of the most succinct descriptions of this process can be found in Rocky Lhotka's book on Business Objects. I get a lot of books to review by publishers and this one had the best explanation
Assuming you don't have the option of using WCF, I'd advocate using WSE 3 (Web Service Enhancements). You can get the toolkit / SDK thingummy at MS's site
To limit the access to only internal machines (as I think your question asked), I'd set up a separate web site in IIS and set it to only respond to the internal IP address of your server.
I would set a firewall rule to restrict access to a whitelist of IP addresses.
Use IIS's directory security IP address restrictions, and limit access to just that internal web server IP address.
If you can't do that then, and you can't setup a username/password on the directory, then use WSE and add a username/password into the service, or look at certificates if you want some fun grin
Maybe I did not understand correctly, but why expose the web methods publicly at all if they're only going to be consumed by the internal server?
A simple HTTP module will work. Just hardcode (or from config) the allowed IP/host and reject all others.
If it is only the internal server that will be accessing the asmx files? You could set them up in IIS under a separate web site or virtual directory, then place some IP restrictions on the site. In properties, go under Directory Security, then "IP Address and Domain Name Restrictions."
Also, for passwords, WSE 3 is the new go-to, but I did find a simple method in a book from Apress called "Pro ASP.NET 2.0 in C# 2005" Chapter 34. (Note, the newer version of this book omits this chapter.) The section is custom Ticket-based authentication.
In this moment what comes to my mind is IP filtering on IIS. Fast to apply, should work in your scenario.
TLS with client certs. See Wikipedia entry to get started.
Be aware that there are ways around whitelisting IPs. Don't get me wrong, it's a great idea, and you should definetly do it, but if your budget/resources allow it, you can expand your threat model.