I have created an STS and a relying website that is able to authenticate using the STS via WIF. In all browsers but IE9 this works well. In IE9, after logging in and using the relying website for about 5 minutes (not consistent, but usually happens after 5 to 10 minutes) the user is redirected back to the STS to sign in again.
However, the user is not really signed out of the STS. If the user simply refreshes the sign in page of the STS, a new tab opens and takes them back to the relying website.
I am very puzzled by this behavior, and can only reproduce it in IE9. Any ideas what might be causing this?
It sounds like your session cookie is expiring too early. Can you check your site's web.config and see what persistentSessionLifetime you have set in the cookie handler (if any)?
This post has some detail:
How do I increase session timeout with W.I.F / SAML tokens / FedAuth cookie
Related
I have a web application built using asp.net mvc. I'm using the standard build in authentication - asp.net Identity (SignInManager & application cookie), although I've hooked this to MySQL back end.
As expected, when the user leaves my web application but returns to it in time before their session expires they can access the authorized pages on the site and when the session expires they are redirected to the log in page.
My question is, is it possible to force them to log in every time they return to the site after leaving it? The scenario being, they closed their browser or navigated away from the site all together.
Appreciate the help guys!
You need to "issue" the authentication cookie as "session" cookie. Session cookies disappear when all instances of the same-brand/same-mode browser is closed. By "same-mode" I mean incognito and non-incognito.
Keeping in mind your scenario, you can use following method.
FormsAuthentication.SetAuthCookie("YourCookieValue", false); //second aurgument is persistent
you can set the persistent value to false so whenever a user closes his/her browser he/she will be logged out.
I am fairly new with developing in ASP.Net and I've searched high and low for a resolution to this, to no avail. I am using Forms Authentication to authenticate users and when I login with user A, I abandon the current session, generate a new session cookie/id and redirect from to my content page and everything works as planned. However, when I open a new browser window and navigate to the login screen, thus starting a new session, the authentication cookie for user A is automatically passed to this session and is part of the request cookies collection. Even worse, when I actually log in as user B and get a new authentication cookie then refresh the browser window for session A, it now has the authentication cookie of user B.
I have no idea why this is happening. I thought the browser (IE9) was caching the authentication cookie because the response-header collection is set to cache-control "private" even though I specifically set the Response.Cache.SetCacheability("no-cache") in my code-behind for all pages. Then I was thinking it could be a threading issue.
Any insight into why this is happening is greatly appreciated, Thanks.
Try different Browsers like Chrome and IE. Because browser share same cookie and temp file even opened in new windows. Above scenario will occur if you try with gmail.com or live.com.
Check your web.config files for session settings.
Check out the following link:
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.enablecrossappredirects.aspx
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
I have couple questions about security in ASP.net and in general.
Where are stored "Authorization" cookies? When I logined in the system and then decided to logout I suppose for this enough to delete cookies from my browser but this not work. Then I rethink that these cookies is supplied from browser stored passwords, but wrong again, since I don't see login/password info for my site there.
And since "Authorization" cookie is always returned in response for 401 code, user stays always logined in the system and I can't understand how to logout.
The timeout for ".ASPXAUTH" - 30 min is recommended, and then cookie expired. Though I login, then after recommended 30 minutes I need to login again (even with sliding property to true, I can just leave a page for more than 30 minutes). But when I login to the most of the sites (such as stackoverflow for example), I can enter here again without logining even after week delay. How it is implemented, is that sites just set timeout for much bigger timespan or there is some other techniques?
Thanks!
Answer to question 1:
Use FormsAuthentication.Signout(); to logout. This will delete the authentication cookie. The authentication cookie is stored in the http-request and in the response as every other cookie.
Rergarding your 2nd question: Your cookie should expire after 2880 minutes. I don't know why it expires after 30 minutes in your case. Also the sliding expiration normally works. Could your browser settings have some influence? Another possiblility could be that the Visual Studio internal web server does not behave like a real web server. Try your settings on IIS.
EDIT:
I think the answer to your 2nd question is here
I've got an asp.net application which seems to forget that a user is logged in after a while.
I'm using the membership provider and when opt to "remember" the log in it remembers it during the session. I can even close the browser, restart and come back and it will still be logged in. But after a while it forgets and it seems to do it at any old time. I've once been logged in and when I went to a new page it was logged out.
The other strange things are:
On my development machine it remembers the log in forever. Even after IIS restarts and recompiles it will remember my login as expected.
I have another application on the same server that does remember the login forever. I compared how they handle login and they seem to be identical.
This leads me to believe that the issue has something to do with the server or perhaps something in the application not directly related to the login and membership code. What could I look at?
Edit:
Looked up the cookie using Fiddler and they seem to be ok.
An Authentication cookie created today expires 2 weeks from now, which is how my config is set up:
expires=Mon, 06-Sep-2010 01:47:51 GMT
Edit:
The problem seems to be that the app pool is recycling and the authentication cookie becomes invalid because it can no longer be read as the machine key has changed. The solution was to add a machineKey segment to the web.config and supply a static machine key.
There are two major possibilities.
Cookie expiration. If the cookie expires / goes away, then you are considered logged out.
Cookie invalidation. Login cookies are encrypted based on the machineKey value. If you do not specify a machineKey, a new one is regenerated each time the application pool starts up (or is recycled). That means that any login cookie encrypted with the old machineKey is now invalid, and you will not be considered logged in.
Check to see what the recycle settings are on your application pool in IIS and see if that corresponds with the timing of you not being logged in.
"Remember me" functionality is done using cookies. Cookies can be set with an expiration date. You need to look into how the cookie is being set (Fiddler is good for this, you can inspect the HTTP header when the cookie is set.)