I have posted the following question concerning ASP.NET web farms.
How to create an ASP.NET web farm?
Guys recommended using Network Load Balancing (NLB) as a primary way of creating a web farm.
However, Wikipedia says that "NLBS is intended for ... stateless applications". Our web application, however, is absolutely "stateful": it is a closed site to which users will have access by login and password, and information for every user will be different: people will see their own trades and operations.
Should we still use NLB in this scenario?
Thank you.
Should we still use NLB in this scenario?
Do not see reasons why not if you follow the guidelines.
The web application is by nature stateless, so even if your users should log-in it does not make the application stateful.
Couple the things which ARE stateful in ASP.NET are:
Session State
Cache
which can be configured appropriately in a WebFarm.
Here is an example on how to configure the NLB.
You can still use a NLB, but you need one that supports Sticky Sessions, meaning that it will always route traffic from a certain client to the same web server. Not the best solution in terms of load balancing, but at least allows you to grow to multiple servers.
I think load balancing is still desirable. You just need to set it up so sessions are "sticky": once a session is open:
http://technet.microsoft.com/en-us/library/bb734910.aspx
Absolutely, yes. There are strategies you can employ to maintain state between servers in your farm. The machineKey settings should be the same for all webservers in your farm so that auth tickets are valid between machines.
http://msdn.microsoft.com/en-us/library/ms998288.aspx#paght000007_webfarmdeploymentconsiderations
There are a few options for managing session state between your webservers:
http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
http://support.microsoft.com/kb/311209
Related
Azure website clarity regarding the instances, are these instances running on multiple machine like a web server farm environment where one client request (session) can be server by different server in the farm.
Issue with server farm asp.net application is that we can loose session variable if that is the case, for this issue to get around we add machine key in web.config that assure client session will always be server by same server so there wont be any lose of session variable.
How does Azure instance work. doesnt it mean we can have 10 websites under same plan let ex s1 Standard.
I am hosting asp.net webform based website on Azure I am confused how exactly instance work. there are lot of article on internet to create confusion.
The thing with PaaS is that you don't have to care about that. If you have a statefull site, you can use the ARR Affinity setting to ensure a client gets always to the same instance:
Adding to Martin Brandl's answer.
An App Service Plan can have multiple instances. These instances run all of the apps in that plan. So it is pretty much like a classic web farm. Except it is way easier to manage.
There is a better way of keeping session information in a web farm rather than relying on sticky sessions with ARR Affinity. Put the session data in a central place. For that you can use Azure Redis Cache or SQL Database. There are ready-made session state providers for these that you can just plug in to an ASP.NET application. That way your session state is not stored on the instances, so you don't need to care if clients hit the same server.
The problem I have with ARR Affinity, is that Azure does not guarantee your instances will remain running. A hardware failure could bring one down and you lose a part of your session data. If you use auto-scale, same thing.
I know this question can be too generic but for purposes of narrowing the question, here is a brief description:
I'm planning to forget about ASP.net UpdatePanel and move to use ajax via JQuery. I am afraid that because of the plain, client-side nature of JavaScript (and consequently JQuery code), any one looking to my web page's source can realize what is the URL of the web services I'm calling and also what are being passed to those web services.
When using UpdatePanel for these types of operations, I'm sure that calling web services is done on server-side and I have no concern regarding issues of information on calling sensitive web services being exposed publicly but now that I'm planning to use Ajax via JQuery, It worries me alot.
Are my concerns reasonable and if true, what are the best solutions for avoiding the threats of web-service-calling-info being exposed?
Clarification: when saying UpdatePanel, I mean utilizing a chain of techiques including ASP.net AJAX, code-behind and relying on server-side Dlls for performing async server-side operations instead of jquery Ajax which requires web services for intracting with server.
There is no way on the internet to protect your web services all the time by just hiding the URL. I am not sure when you say your updatepanel does the web service call from the server you are not taking the true power of AJAX.
One way to secure your web service is to use the authentication in the web service side. For example you need to send some authentication key every time you access the source, and this is very common, you have so many public web service who protects it self using auth key like OpenId implementation. In case you do not want to change the web service logic I think jquery way of AJAX is not a secure option.
Here's a thought, you can have two levels of web service, one which will open for all that you can use in the jquery. From the current web service, from the server side call the other secure web service. Even now you can configure your incoming request for some specific machine IP.
In this case other than your own server no body else can access to the web service securely kept behind the firewall. It is something similar we do while connecting to database server from application server.
Let me know if this helps.
I'm going to state the problems my answer is hoping to solve:
Assuming you host your services on a machine other than the web server, the problem is you give potential attackers the name/address of those machines.
Attackers can write scripts/bots to scrape your data.
Attackers can focus on your web services and try to hack them/gain access to your network.
Attackers can try to perform a DoS/DDoS on your web services.
The solution I've used in the past is to create a light weight proxy on the web server such that all AJAX calls simply point back to the current domain. Then when a call comes in, it is simply routed to the appropriate web service, which is hosted somewhere internally on the network.
It creates one additional hop on the network, but it also has these benefits:
It hides the actual IP of the machine hosting your services.
You can easily lock down that one web server and monitor unusual activity. If you see a spike in activity, you can potentially shut down the web services. (If you use a different machine, you'd have to monitor two boxes. Not a huge problem, but easier to monitor just one.)
You can easily put a distributed caching layer in the proxy. This protects you from load/denial of service (DoS) attacks and obviously supports normal web service traffic.
You can hide the authentication at the proxy level. The public calls won't betray your authentication scheme. Otherwise an attacker can see what tokens or keys or secrets or whatever that you use. Making a proxy on the web server hides that information. The data will still flow through, but again you can monitor it.
The real benefit in my opinion is that it reduces the surface area of your application which narrows what an attacker can do.
Since you refer to ASP.Net, know its viewstate can easily be decrypted. There's no failproof ways to protect your code (not to say urls called).
If you're web services are called with some parameters that could allow unrestricted and dangerous actions, then you'd better start using some users/roles/rights management.
If you're worried about "man in the middle" attacks, you best option is to use https.
(A question of similar vein has been asked before but both the question and the accepted answer do not provide the detail I am looking for)
With the intention of running an asmx web service under a dedicated domain account what are the usage scenarios and/or pros and cons of using an Application Pool with the identity of the domain account versus Impersonation?
We have 3 small internal web services that run under relatively low load and we would like to switch them to running under their own domain accounts (for the purpose of integrated security with SQL Server etc). I appear to have the choice of creating dedicated app pools for each application, or having a single app pool for all the applications and using impersonation in each.
I understand app pools provide worker process isolation and there are considerations for performance when using impersonation, however those aside what else would dictate the correct option?
Typically, you will choose different identity for worker process (or do ASP.NET impersonation) because there is need to access local/network resources that needs specific permissions. Obvious dis-advantage is that your application code may run under more permissions than it may need and thereby increasing the vulnerability against malicious attacks.
ASP.NET impersonation would have more overhead because user context needs be switched for each request. I will suggest to go with separate app pool approach - only disadvantage with app pool approach is that you have process for each one of them and so there will be overhead (from OS perspective) for each process. If your applications are smaller and don't have strong memory demands then this should not be an issue,
If you want your web services to connect to SQL via Windows authentication, you will almost certainly want to set up each application with the dedicated app pool option. This requires the least amount of setup and administration.
If you go the impersonation route, you'll need to account for the "two-hop" issue. When a user calls a web service that is using impersonation, the web service can access local resources, as that user. However, if the web service tries to connect to a non-local resource (e.g., a database running on a separate server), the result will be an authentication error. The reason is that NTLM prevents your credentials from making more than one "hop". To workaround this, you would need to use Kerberos delegation. Delegation isn't difficult to set up, but it does require Domain Admin privileges, which can make things difficult in some corporate environments.
In addition, using impersonation means that you need to manage database permissions for each user that may visit your web service. The combination of database roles and AD groups will go a long way in simplifying this, but it's an extra administrative step that you may not wish to conduct. It's also a possible security risk, as certain users may end up with privileges that are greater than your web services are anticipating.
Impersonation is useful when you need a common end user experience with other Windows services that are based on Windows security.
For example, Microsoft SharePoint servers use impersonation because you can access SharePoint document libraries with web browsers and with the standard Windows shares UI (connect / disconnect to a network share, based on the SMB protocol). To ensure security is consistent between the two, in this case, you need impersonation.
Other than this kind of scenario, impersonation is most of the time not useful (but can cost a lot in terms of scalability)
Application pool pros:
You don't have to be a .Net programmer to understand what's going on.
The security aspect leaves the domain of the programmer and falls under the remit of infrastructure
Easy to change through IIS with proper saftey checks that the username is correct when setting up the app pool. I.e. It won't let you enter an incorrect username.
Impersonation pros:
Privileges can be documented and traced back through changes to configuration through source control history if configuration files are stored there.
Impersonation cons:
To change the user, you need to be familiar with .Net configuration rather than just setting up a website
Not sure I can think of much else.
My gut says to go with different application pools for each of the websites but it's your party.
I would advise you to check the following page for security details...
https://www.attosol.com/sample-aspx-page-to-show-security-details-in-asp-net/
Once you are done with this, you will see "precisely" how impersonation changes the identity.
Right now, my site is served by a single server, but I anticipate the need to increase my server capacity, soon. Instead of splitting my websites up among multiple servers and having to manage sessions across servers, I want to have multiple web servers all with the same code base on them and use router based round robin load sharing to distribute users to each server. And once a user hits a web server, have him stay with that web server throughout his/her whole session. To my knowledge, I don't need to have any special asp.net code to facilitate this.
Does anyone have any caveats or comments for this approach?
What you are talking about is called sticky sessions or session affinity. If your router supports this, then you are golden.
The only caviat is that the load balancing won't be perfect. If you have a few high-load users who all end up randomly on the same server, they will staty there until the sessions end.
I have implemented this kind of load balancing where I work, and it requires no special asp.net code to implement.
Most (perhap all) load balancers do have the ability to enforce "sticky" sessions where users on the same IP are directed to the same web server on every request. There is no code change required to accomplish this. There are two caveats that come to mind:
Using sticky sessions will mean that the traffic load will not be distributed as evenly as it would if you were not using sticky sessions. However, the distributionshould be"even enough" IMO.
There will be a very small percentage of users using proxy servers that may come in on different IPs on different requests. These users may experience "odd" behavior as they get passed to different servers.
Another characteristic of this configuration is that if one your servers go down the sessions of the users on that server will lose their session as well. I think this is one of the most commonly used setup since it does not require any development effort if the router supports sticky session or session affinity.
As others have mentioned, you should be able to turn on Sticky Sessions on your load balancer, that should take care of most of the "stay on one server" issues for you.
However you will want to ensure you have put settings in place to cope with a user landing on the wrong server mid session - Sticky Sessions are usually based on IP address, and users IPs can change mid session if you're unlucky, or a server may go offline, and the user will be directed to the other server.
You should make sure that your MachineKeys are the same across all servers - this will ensure that you can decrypt the viewstate correctly on all servers.
If you own the servers, you can do this in the machine.config, otherwise you can set it at the application level in the web.config, more details can be found in this how to:
Configure MachineKey in ASP.NET 2.0
There are some slight differences if you're running on IIS 7.5 - Tess Ferrandez has more details in a recent post "Forms authentication fails after installing IIS 7.5".
The other thing you'll probably want to do is move your sessionState from InProc to either Sql or StateServer.
This seems trivial, but I've never had to worry about it before and my Google skills are failing me. How far-reaching is the in-process session bucket for ASP.NET/IIS6, in the sense that you can call Session["whatever"] and get the same value back? Obviously it can't stretch across different servers or application pools (I think). What about different web sites in the same application pool? Can those two see each other's session variables for a user? What about two different virtual directories each with their own web.config?
Thanks!
AFAIK the in-process session has an AppDomain scope, so no, two web applications running in the same pool cannot share an in-process session. Actually the name "in-AppDomain" would be more appropriate.
Obviously it can't stretch across different servers
Sure you can. This MSDN Article has more details.
It can stretch across servers in a farm if the asp.net session is stored in the database.
Perimeter of session is strictly within the one app domain for security reasons
This sounds like you would be better off storing a database value than storing it in a In-Proc session[""]. If you have a state server then the session can be accessed across all machines that use the same state server. In-Proc is just what it says. It's stored In the Process of that single computer.
If you wanted to share Session across applications with a SQL Server backend, there's an article on how to do that.