We have 5 balanced web servers with various websites.
What I am trying to achieve is to ensure a single login.
i.e. the same user account cannot login to the same website more than once at any given time.
The method i'm considering for solving this, is to share session amongst the servers so I can control which session is assigned to which account. I can then have control over my logins. If a user logs in and there is already a session assigned to their user account, I can just expire the first session or reject the login.
I don't want to lose the benefit of the balanced servers, so using a single Sql Server as my session state server, or a single server to handle login is not an option.
Is distributed session (something like Scaleout Sofware) the correct approach to achieve this?
Or is there another mechanism to handle single login that i'm blissfully unaware of?
You have two set of problems here:
1) Allowing just one connected user in a web farm scenario
2) Detecting user logoff
To solve the first the only solution is a central storage for some kind of user state, using a central server to store the ASP.Net session or some other kind of centralized user state. This central storage can be SQL Server using the native management of session state (btw also Oracle, from Oracle 11, can support session storage), the AspState service or an external solution, like ScaleOut (as you said) or its open source alternative memcached (see https://sourceforge.net/projects/memcacheddotnet/). Or you can design a simple centralized web service that check active logins against a SQL Server database, this way you can also quickly create reporting tools about logged on users and so on.
Real problem, in my opinion, lies in the second part, that you need to maintain the different "wrong logoff" scenarios that are available in a web world (like closing the browser due to a crash or shutting down applications without logging off), giving you application some way to gracefully work with user that has an old session enabled (as you said simply expiring the first session can work).
Keep also in mind that using a state server like SQL server will not make you loose the balanced servers, if's the way of working to have a web farm environmet and sharing session, only problem lies in performance (if session state become large) and the cost involved in using SQL Server if you do not already have the proper license.
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 have an ASP.NET Application which runs an multiple Web Servers in Azure (these are all virtual machines and not Azure Websites).
If a user logs himself in (currently forms authentication) everything is fine but if he clicks on a link he might get redirected to another server in the server group where the session cookie is not set.
How could that be solved in azure so that a user is logged in on all machines or is there a way to "bind" a user to a specific server so that he won't jump between the servers?
Thanks for your help!
metabolic
You have to change the session state to be saved in an external persistence solution, like SQL Server or Redis, instead of InProc (which means in memory) which is the setting you have now. The steps to do that are described here for SQL Server. Then if someone ends up in a different server, he'll still be authenticated as the session will be loaded from the persistence solution.
Basically my question is i have a website which was developed around 3 years ago, while development it was proposed that this site will be used by few people on internet.
But now it seems like many users are accessing the website. So we have planned to create a Web sever Farm where we have multiple servers for our website.
major problem in development is old website used InProc Session state and now since we are upgrading to multiple servers we want to change InProc to Outproc i.e StateServer Session State.
Can you guide me on this upgrade and how can it be achieved in simple and easy way rather than changing the coding on each pages wherever sessions are used.
What you going to have here is that you move your site to many web servers and the actual issue here is "how to keep the same state for each user regarding the server".
There are two options.
First option is to setup the router that split the users to the server, to use the "Sticky option", meaning that each user is stick for his session to one server, and one only. In this case it did not matter if you use inproc or sql server session, as long as the router make good job. This is the case of course that you do not use any other database for common data.
Second option is to use an sql server and move the session to the server, but here the server must be on one server and the others server's gets his session data from this one. Also you setup on web.config the same key machine for all web servers.
So for this case you need.
To setup a common/shared SQL server on one server
To install on this the session database (actually run a script from asp.net)
Setup the web.config to use this database as session
Setup the web.config to have the same machine key.
In the case that you use a database for other data, then you place this database together with the session database, and you make a share connect to that database also. The point here is that the data must be live on one computer, and the other computers connect to this main one for the data.
I have inherited a conventional three tier web app with ASP.net 2.0 for the UI, .Net web services (ASMX) in the middle tier and SQL Server 2005 for the DB. This is currently an intranet application with the only users being company employees. Currently the application uses Active Directory (AD) authentication.
At the login screen, the user is presented with username / password dialog. The middle tier makes a simple call to the AD to check the username / password. If ok, then a sessionId guid is generated and sent back to the UI. This sessionId is then passed on every subsequent call from the UI within the session. All methods in the middle tier first check the validity of the sessionID against a simple session table in SQL Server, before processing the request.
I now need to make the web services middle tier of the application available to a new UI that will be available to the public internet. I don't need to worry about authentication because that will be managed by the new UI. However, I don't want to leave the web services completely open without any security. I just want to be sure that the system calling the services has permission to do so. I don't want to burden the new UI with having to maintain the sessionIds currently used.
Any views on the best way to secure the services when being called from the new UI? I guess I could use x509 certificates but I've done this before so I'm not aware of any disadvantages (performance?) or how to go about the implementation.
The new UI has been developed used .Net 3.5. We can install .Net 3.5 on the middle tier so I guess we could benefit from using WCF?
I don't believe this is a problem that is suited for cryptography. It would be better to limit access to your web service using an IP restriction. If this data is being transfered over an insecure connection like the open internet, then you could use ssl to verify the client and server as well as keep the transmitted data safe. You could also use VPN which is probably the easiest to implement.
I am concerned with your session table. I believe this introduces a lag time for revoking user accounts. If this session doesn't have an expire time then it would make it impossible to revoke a user account. After a user has logged in how do you kick them off?
One solution is to have the ASMX web service query active directory for each request, if your AD server isn't under a heavy load then this should be fine. Keep in mind that AD is a very efferent database in its own right.
Is there a way to share session among asp.net balanced applicatiosn without saving session in DB (i.e. without using SQLServer sessionState)? Actually, could load balancers take care of that by themselves?
To share a user session, yes. You have two options:
User an ASP.NET state server and have the web servers point to that.
Enable sticky sessions on the load balancer, so that once a session is started on a particular machine, all further requests for that session will go to the same machine. (really this is the less ideal of the two as it can still have problems if the app pool resets etc.)
There are other applications from MS etc, that you can use to store state also.