I am using an MVC app to manage authentication. The issue I have is with chrome because it never actually kills the session because it runs in the background after it closes by default. I do not want to enforce all the end users to change this setting because then it will kill hangouts etc.. So I am wondering if I can use any standard web.config setting to handle this or do I need to make an ajax polling interval to keep updating the cookie expiration?
The ASP.NET session consists of 2 components the client-side http session cookie and the server's session storage provider. Suppose user has SessionId 1. If you delete session 1 from the server, the user returns and a new session is created with SessionId 1. If the user deletes the session cookie, the server keeps running session 1.
What you're asking for is generally not possible. There's no way you can force a user to send a request to your server when they are exiting your site or the browser. There is the javascript beforeUnload event which in some situations would allow you to send a request to /sign-off in some situations. The obvious limiter is no network access = no message.
The standard resolution for orphaned sessions is for session scavenging policy to clean them up. Some developers choose to use persistent storage to eliminate scavenging altogether such that a shopping cart would never disappear.
The only reasonable solution (which is still overkill) that would reach your goals. You use SingalR for a persistent connection of the user to the server and you ping them from the server. If the connection fails to respond you abandon the session. This will be a fragile process and if you don't make very very sure the user is disconnected you will have lots of support calls from users wondering why they are continuously logged out while browsing your site on cell phone.
Related
My requirement is user should not log in from multiple browser or system simultaneously in application. For this I maintained the flag in database, so whenever user is logged in I am updating flag as yes and when he logged out I am updating it as no.
My issue is if user close the browser window without logging out from application then I am unable to update the flag. So next time when user try to logging in application, It is saying user is already logged in.
I tried using Onbeforeunload event in master page, but whenever I am changing the menu in my application. It is firing that event. For updating the flag I used page methods. But this is not working properly.
I would say, send often via a ajax call to your API that a 'ping' to confirm you are still online. If there is no ping or page change after 3 minutes, I consider the user has been logged off and it sets him as "logged off" in database.
At least, I do this using javascript, but i'm sure you can also in your client-side part of the ASP.NET app you are making.
You can't handle this only by client-side code, using e.g. beforeunload, because the page/browser may be closed for many reasons (e.g. lack of electricity).
What you can do is:
Scheduler on your backend which verifies whether an user did some action since e.g. 1min. In that case you have to update information about user action in your DB after every ajax requests (Hugo Regibo suggested ping requests).
Disadvantage od this solution is this period - when an user turns off the page then he will be not able to log in again for 1min.
Instead of a scheduler you can verify logged-in users (I assume you keep them in a DB table) after each requests.
Use web sockets, you will have continuous connection and you will be notified about closed connection immediately. Disadvantage of this is web sockets don't scale so good as stateless HTTP.
Besides that I don't know whether you use iis with a session provider or not? And when an user closes the page and opens it again should be able to log in with his saved credentials. You should write more of how your project looks like.
I would do it by saving a Session object for each login call. A session ID would then be stored in the user's cookie or authentication token. Each call to the system would validate the user via their session ID. If that session has been invalidated, they just get sent to the login prompt. Whenever the user logs in, it invalidates all of their other sessions.
This way the user could be in their browser on their machine, navigate away, close the browser, and come back to find their session still alive without having to log back in. But, if they log into another machine, then their old session would be invalidated.
If the session is stored in proc
The user logs in, closes the browser directly and reopens it after an hour. Would he need to log in again?
If the web application uses cookies and cookies are enabled on the users browser...
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the web application uses cookies and cookies are disabled on the users browser...
If the web application uses persistent cookies and cookies are disabled on the users browser...
If session is stored in state server and situations are the same, then what would happen?
When a session is created (assuming it is a normal session), a cookie is sent to the browser that looks something like this:
SESSION_ID=437b930db84b8079c2dd804a71936b5f
Sessions can be used without cookies if the session identifier (in the example above, 437b930db84b8079c2dd804a71936b5f) is passed around as request parameter instead of a cookie; however, this is rather uncommon and it is generally considered bad practice.
All session information is stored server-side, and the session identifier is used behind-the-scenes to decide which set of information should be recalled (if any) for each request. Thus we get to your questions.
If the web application uses cookies and cookies are enabled on the users browser...
If the web app uses cookies and cookies are enabled on the browser, then there should not be a problem. With a standard session implementation, the cookies will be non-persistent, though, so the user will need to login again if he/she completely closes all instances of the browser.
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the session-id is stored in a persistent cookie and user's browser respects that by persisting the session identifier cookie to the disk, then the session identifier will be sent even if the browser is fully closed and restarted. However, please be aware that most web frameworks have a garbage-collector-like system that deletes data for sessions that have showed any activity over a certain amount of time. So, for example, let's say my website requires activity at least once every 4 hours to keep a session active. If I login, receive a persistent cookie with my session ID, close my browser, and come back 5 hours later, then I will need to login again because my session information would have been cleared from the server even though my session ID cookie was persistent.
If the web application uses cookies and cookies are disabled on the users browser...
Bad news bears. You will either need to find a way to use a cookieless session (passing an identifier as a parameter for each request), or you will need to ask the user to enable cookies. There is no way around this.
If the web application uses persistent cookies and cookies are disabled on the users browser...
Same situation as #3. If the user has cookies disabled, you are out of luck. Either they need to enable cookies (at least for your site), or you need to find another way to pass around information between requests.
Session is stored in server memory (unless a state server or persistant store is used) but relies on a cookie to identify the session. If cookies aren't available then session won't work since there is no way to identify the user. Cookieless sessions can be used to get around this. Cookieless sessions aren't recommended as they can be hijacked with the session identifier in the url.
If an expiration isn't set on the cookie then it will be lost once the user closes all browser instances (they share memory) and not just the one visited through the website.
If the user has cookies disabled, then cookies aren't available for use by the application. People aren't as worried about cookies now as they were in the late 90's (lots of "security" people raised warnings that cookies could be used to store all sorts of things on your computer, even viruses).
I have an asp.net Web Api 2 / Identity 2 application that requires a user to be authenticated. The authentication works but I notice that when I restart my local development machine and try to access a method that requires authentication then I get a failure.
As my application is unchanged from the asp.net sample then I think it uses cookies to store user data on the client. Where and how does the Server or IIS store information on which users have authenticated? Does it do this just the once or on every HTTP? Is there a difference between my using Token or cookie authentication in the way that the authentication and also authorization is checked on the server?
I think you are misunderstanding how authentication works with ASP.Net. As an example, let me show you some cookie details for a site of mine that uses Identity (note the token is actually in the cookie, the two are not mutually exclusive concepts):
Name __RequestVerificationToken
Value afeILhaIvRr56jXXXXXXXXXXX
Host site.azurewebsites.net
Path /
Expires At end of session
Note that the cookie, by default, expires at the end of your session. That means when you restart your development machine, your cookie is expired and your token is no longer valid.
In particular I have read that with token authentication then there is no need for continual re-authentication every time a request is made to the server
You need to understand that HTTP is a stateless protocol. Each request happens in a vacuum, and therefore you need to pass some data back to the server so that it can tell that the person who authenticated with Request A is really the initiator of Request B. Almost always, that piece of data is from a cookie. So, every request does indeed re-authenticate, and typically with a token in a cookie.
The only piece of data about your session that is stored on the client is the cookie (unless you are doing something atypical). The rest is on the server. How it is stored can vary:
Inproc: Easiest to setup, sessions are stored in process. So when your server or app pool is restarted, that data disappears
State Server Mode: Sessions are stored in process, but outside of the ASP.Net worker process, so the application can be restarted without losing session data
SQL Server: Unsurprisingly, this stores data in a database. Very resilient, but more work to setup. Also your best option if you are on a web farm.
ref: http://msdn.microsoft.com/en-us/library/vstudio/ms178586(v=vs.100).aspx
Expanding on the great answer by Chris, I would like to add that there are two possible models here. In forms authentication (which is the default membership type for asp.net) the cookie can either store authentication information and then it's called a ticket or the information can be stored in session, with the cookie being a simple identifier for "reconnecting" the authenticated session with the requesting client on each subsequent request.
This "reconnecting" happens in the Application_AuthenticateRequest method of the global.asax. If you are using the default forms authentication storage, i.e. an SQL DB created for you by the framework, the reconnection will be done automatically. If you are using a custom authentication store (like accessing active directory yourself or a custom users table structure) you can override the the method and reconnect the authenticated session using your own implementation. In any case, the authentication data is populated in the User.Identity object's different properties. From that point, if you use the [Authorize] attribute, the framework accesses the object to check if the user is indeed authenticated and authorized.
I any case, the authentication information is tied to both the cookie and the session. Assuming your session is InProc, like Chris said, when the session is lost (through timeout, app pool recycle or restart of the dev machine) the server-side of the session is lost and your authentication / session cookie is replaced by a new one on the next request.
EDIT: Ohh... and one more side comment. Make sure you distinguish between authentication and authorization. The client is not re-authenticated on each request. Authentication is the process of providing your credentials and being identified by the server. Authorization is, now that the server has verified who you are, on each request it checks if you are authorized to access the resource you are requesting.
The server doesn't store information about who's authenticated and who isn't. Depending on your authentication mechanism (forms, tokens?), typically, when a user logs in, the server will return some form of authentication token that the client should pass back to the server on each API call.
Without knowing more about your configuration, it's difficult to explain why when you restart your server you have to re-authenticate, it sounds like the authentication token generated by the server is invalidated on restart.
Where and how does the Server or IIS store information on which users have authenticated?
IIS does not store state based on cookie authentication. Everything is determined based on the request. Either a request has the correct encrypted information, or it doesn't. If you look at a default Forms authentication in ASP.NET, you will find a cookie called .ADUAUTH ... this cookie has all the information to authenticate the request. If the cookie is half expired, it will be reset, but that's all IIS does.
Does it do this just the once or on every HTTP?
Every HTTP request is unique, so yes, per HTTP request.
Is there a difference between my using Token or cookie authentication in the way that the authentication and also authorization is checked on the server?
It's always checked on the server: To find out more, check out: How ASP.NET Security Works: http://msdn.microsoft.com/en-us/library/ks310b8y.ASPX
I think my answer could be a little contradicting to all of the above.. But I think If I understand right..
IIS stores inside the memory space of the ASP.NET worker process, i.e the session data in the RAM.
The storing of authentication state depends on the authentication model you are using. For example: if you are using the Federated authentication, through ADFS, then when a user loads your web page he is required to sign in providing his credentials. The ADFS then sets the authentication token which is stored in the session data, the session id is stored as cookies in user's browser. The server has the mapping of Session Id to its session data.
Now the user is authenticated. The ADFS looks for authentication token to mark a user as authenticated.
When you restart the server, the session data is lost as the data is stored in RAM.
There are ways to handle this, there are 3 types of session storage:
1. InProc (Stored in memory space of ASP .NET Worker process - RAM)
2. State Server (Stored out side of ASP .NET worker process, like on cloud Azure storage)
3. SQL Server session storage (Stored in SQL server)
I think you are adopting 1, because of which you encounter the problem.
In cases 2 and 3, the session is not lost when you restart the server.
Several things --
Token based authentication is not really authentication. It is just issuing you a unique token (can be a guid, unique string, etc) and then associating it with something (like your IP address) and saving that association server side (in a database?). Now whenever you use that token, from the client app, the server checks the association already stored and serves or denies or request.
In many ways, it is very similar to using Cookies to maintain authentication. Only, token-auth was designed more for web services operation than for UIs.
In short: Out of the box, the membership provider will run it's authentication method and upon success, it will create an auth ticket/token/cookie that will be stored from the site. In addition to this, there is a session cookie that is stored with the site as well. When you make a page request, it'll pull these things and use them to determine whether or not you are already authenticated. If it finds the ticket and sees that it is still good, it'll allow access.
When you restart your local environment, the session and it's information is destroyed which is why you have to log in again.
There is an entire pipeline in the framework that makes all of this stuff happen (having to do with authentication, authorization, and identity) and there are number of ok articles on the interwebs explaining this, but imo, they're almost all incomplete or hard to follow. If you want a great soup-to-nuts explanation, PluralSight.com has some training videos that will deconstruct and explain the entire pipeline for you. Understanding the pipeline can help you implement your own custom authentication, and I highly recommend it.
I've been getting into the (relatively) new Web API that shipped with VS 2012 / MVC 4 / .NET 4.5, and have a custom message handler that handles authentication up and running. I also managed to hook it up to an old .NET 2.0 Membership Provider which was great.
I am now tackling the "authenticate with every HTTP request" issue by using a token in the HTTP request header, which I am comfortable with doing.
Now, for mobile apps when a user opens the app I show a login screen the first time, and don't show it again unless for any reason I get the "Unauthorized" message back. But for my web browser based projects I log in once and the browser (as long as it remains open) will remain authenticated.
What's the best way of forcing a time-out with this sort of authentication? I would prefer to log out based on inactivity, if anyone has done this. This one has me a bit stumped, so any guidance is appreciated :-)
Thanks!
There are two idle timeouts you need to consider.
Server Side idle timeout which expires to token you referred to
Client Side (mobile app) idle timeout which directs the user to re-enter credentials
For #1, You'd have to keep track of which tokens are active, or when they expire, etc... there are multiple ways to do this. How I'd recommend you implement it depends on if your deploying to IIS or Azure and if you'll be scaling out. In general though you want a central location where this information is stored. A DB works, but is relatively slow. Session State could work in Azure as the Session State can be shared across servers via App Fabric, but in IIS, you'd have to use an additinal component to share session state across the servers. Same holds true if you use the HttpRuntimeCache in .NET
It should also be noted that doing such checking server-side is critical so as to prevent someone from hijacking the token you refer to depending on how you ultimately decide to implement things.
For #2, What we did in our iOS app was keep track of the idle timeout. Each time user give input of any kind (e.g. BeginTouch event) in the app, we stop our idle timer and restart it. The timer is configure to take the user to the login screen should the timer fire. This same sort of thing should work well in Android, WP7, etc.
Suppose I have logged into an application which is running from IIS. Now I haven't logged out, but closed the browser. And when I'm accessing the application again, it defaults to the login page. How does IIS recognize that it is a new request and redirects the user to the login page?
I have another question. Suppose if I'm not closing the browser, which I used when I logged in. I'm opening the new browser to request a page from same application. IIS recognizes that it's a new request to the application and redirects the user to login page. Why does it not use the existing session or cookies which the first browser uses?
Please don't get irritated of my continuous questions... I am having huge confusion.
We say HTTP is a stateless protocol. Once the page is requested I have logged in. And the HTTP protocol connection will be terminated between IIS and browser, right? Then I am navigating to other pages in that logged in application. Now IIS recognises the user has logged in on this browser. But when I open a new browser and request that application, how does IIS recognises it is a new request? Since the HTTP protocol is disconnected, how does it work in the first case?
As you've correctly said, HTTP itself is stateless, and each request is technically separate from every other. Sessions, as used by web sites, are a workaround for that. What happens, normally, is that the server stores whatever info it cares to maintain between requests (like the logged-in user's username and/or ID, for example), and assigns that information an ID (called a "session ID"). It then tells the browser that session ID, in such a way that the browser can hand the ID back when it's time to make another request. If the browser plays its part and provides the session ID, then the stored information can be retrieved, updated, etc with each request, providing some degree of state even over a stateless protocol.
Sessions are usually implemented using cookies. That is, the server hands the browser a cookie with the session ID, and the browser hands back that same cookie with each request until the cookie expires or is otherwise forgotten. Some cookies (so-called "session cookies") aren't saved, and are forgotten when the browser is closed. A freshly opened browser doesn't have any session cookies to pass, so if the server uses session cookies to do sessions (which it should), it will consider the user not yet logged in and bounce them to the login page if they need to be logged in.
Session cookies will usually be shared between tabs in the same browser, and will sometimes even be shared by windows opened by "File > New Window" from an already running browser, because both of those cases will typically just be a part of that browser. But if you start the browser from the Start menu, or however your OS lets you start a program, it's a whole other process -- and session cookies are rarely shared between processes.
The server typically also only remembers sessions on its end for a limited time (anywhere from seconds to years, depending on the server and/or site settings) after each request that uses the session. If the browser passes a cookie that corresponds to a session the server no longer remembers, it'll act as if there's no session at all. Which, in cases where you have to log in, will again bounce to the login page.
There are cookies that are passed always no matter are you logged or not. They are mapped to session in IIS.
Check out the following articles. They might be helpful.
IIS Dropping Sessions
Session Management in ASP.NET