Maybe I'm missing some fundamentals about this, I just don't get why Form Authentication is not build in top of Session.
I've had some issues with Form Authentication timeout and Session timeout, I understand how to get arround those issues thanks to blog posts like this one.
But why are they separated?
I just don't get why Form Authentication is not build in top of Session.
Forms Authentication uses cookies which are common in all applications. Only the currently authenticated username is stored into the cookie. The session on the other hand could store arbitrarily large values as it is stored on the server. You cannot persist arbitrary large data into cookies. The session state has lots of problems. For example if you are running in a web farm you need to ensure that you are using an out-of-process session persistence instead of the default InProc so that all nodes of your web farm could share the same session data. Personally I never use sessions in my applications. The very first thing I do is to ensure that I disable all session state in my web.config:
<sessionState mode="Off" />
This way I am sure that no developer working on my projects would ever do the mistake of using ASP.NET sessions. They turn web applications which are intended to be stateless into stateful.
With cookies you do not have such problems. You could throw as many nodes you want to your web farm to face increasing user load without ever worrying about any state on the server.
Basic because some may chose to use only one of them, and because they are two different modules - and both gives the interface to make a custom one.
Also one user can have session with out have never been authenticated.
Also some other (like me) can made totally custom session module, but keep the Authentication module.
So this is two different modules and they can not be connected.
Related
I wanted to try this code/solution to my ASP.net (VScode 1.69.1) but I am not sure where is the "Global.asax". Anyone know how I can apply the code below to asp.net core?
https://teknohippy.net/2008/08/21/stopping-aspnet-concurrent-logins/
I would not advise you to use that code, it wasn't even good advice back in 2015, but we can explore the concept and it's flaws which might help you come to a better overall solution.
This post will provide some context to the issue: Single Instance Login Implementation but is not a direct duplicate. The original source article does actually go into better detail about the general issues with this approach: http://www.nullskull.com/articles/20030418.asp
Using an In-Memory cache is not a viable option for production as multiple instances of the application would not share the same cache, especially if the application is hosted across multiple servers or serverless infrastructure that is configured to scale out beyond a single instance.
If all you want to do is block new logins, if the user is already logged in, then a server-based or cache concept itself is the right solution, conceptually to enforce a single instance across different browser sessions and across multiple servers will require that there is a server-side cache or store that holds the source of truth for all active connections. This could be in the form of a database or a distributed cache like REDIS.
But this is not a practical model for how users actually use their browsers and devices. Instead of blocking new logins, it is more practical from a user point of view to expire or force close the existing logins. The problem with only blocking new logins is that if the user doesn't have access to the original browser session that holds the login, then there is no way to log out the previous session, you would have to wait for it to timeout. The challenge with being able to expire a login session is that your clients and the server code must be designed to round-trip to the session store to validate the session token. Most default JWT or even cookie implementations do not do this, they will rely on the expiry or validity information in the token itself, and bypass consulting the store.
Instead of the article you have found, please try these resources:
ASP.NET Core security topics
Can I force a logout or expiration of a JWT token?
JSON Web Tokens (JWT) are Dangerous for User Sessions—Here’s a Solution
Once again the confusion related to MSDN documentation with respect to Session Management.
I went thru the Session Management Article in MSDN, and found that it is stated in the article that - "we can Store session-specific data on the server for use across multiple browser or client-device requests within the same session."
Can anybody tell me how is it possible. for e.g. if you have two browsers i.e. i)Firefox and ii) Internet Explorer (IE).
Now, If I am running asp.net application (which uses stateserver to manage sessions) in Firefox. And again the same application I ran through IE (without closing firefox session). Is that means that both the browser will share the same session? I guess "NO". Both the browsers will run with their own sessions, which is different from each other.
Secondly, I found that the two statements in the article are contradictory with each other. It says that - "Session state is similar to application state, except that it is scoped to the current browser session" and on other hand it says that - "It Store session-specific data on the server for use across multiple browser or client-device requests within the same session"
So, if its scope is limited to the current browser session, then how it can be use across multiple browsers?
It is a little confusing, but I think you're misinterpreting the statement. They are referring to multiple requests, not browsers or client-devices.
Session is indeed scoped to the current browser session, persisted with cookies or query strings.
In general, sessions are handled through cookies. Each browser implementation (IE, Chrome) has its own cookie store. Therefore, different browser implementations aren't going to be able to share sessions without some significant workarounds.
Multiple instances of the same browser can reference the same session because they all have access to the same cookies. This can be described as "multiple browsers".
My web application has 2 types of users: non-authenticated visitors and authenticated customers. I'd like the pages that visitors see to work with InProc session and, as soon as a user moves to the the login page, create a new session that works using SQL server session mode.
Is this possible and if so, how is it implemented?
Thanks for your suggestions.
You can only have one sessionMode per Application (Virtual Directory).
You can make 2 separate applications with single-sign-on , to the user it would look like 1 Application.
That is not 100% the same, authenticated users that visit the public pages would use InProc. Up to you if that matters.
On the other hand, are you sure this is worth the effort at all? You can't use the Session for data in a multi-server + InProc scenario anyway (that may depend on your IP setup). And storing (small amounts of) data in the SqlServer shouldn't be much of a problem.
So i have a custom CMS running under .Net 3.5 written entirely in c#. The engine is optimized to render for mobile devices, but also server to normal web browsers. It also supports cookieless sessions. Great...
I've chosen not to cache anything (including browser data) in order to control the rendering completely from data. This has been all good until lately.
The engine implements a basic login function that simply logs the user state within a session object.
The behavior is rather strange. User will click through the site no problem. Then login. The login will either go through successfully or just redisplay the login screen, suggesting a cached page being returned or redisplayed... If the login is successful the concurrent page hits will switch arbitrarily between logged in and logged out state... Also suggesting either the session state is not accessible or a cached page being returned.
I have debugged the hell out of the thing.... including using fiddler and the like. When debugging the behavior disappears.
Huh?
One of the sites running on the engine is http://www.wiseguy.mobi (sorry customized for South Africa, so you'll probably not be able to get the password Text Message)!
Ok, so i've been a dumbass...
The issue was related to the fact that my IIS application was running 2 WorkerProcesses. Thus InProc Session state would return different session object states when the user hits either of the worker processes.
This is why the SQL SessionState persistance has resolved it. Either was its set up rather nicely now, and the issues have been resolved...
I have a web application that once signed in, personalizes almost all pages.
I want to be able to have some very specific pages locked down with SSL that may have sensitive information. From what I have been able to find, once you sign in via an SSL sign in page (area of the web site), the session information which I use to store a lot of personalization and user credentials is not available to the non SSL portion of the web site since they are considered 2 seperate applications.
This MSDN document pretty much says what I am talking about: MSDN Doc
Note: If you use this type of site structure, your application must not rely on the user's identity on the non-SSL pages. In the preceding configuration, no forms authentication ticket is sent for requests for non-SSL pages. As a result, the user is considered anonymous. This has implications for related features, such as personalization, that require the user name.
I am also not using forms authentication. When a user signs in a session object is made storing their credentials including their IP. If this session object exists for a particular user with the same IP then they are considered 'signed in' and the personalization features are enabled.
So my question is, are there any work arounds to this so that say my sign in page and some other page are using SSL, the reset of the site is not, and all pages have access to the same session variables?
If not can anyone suggest any other methods of accomplishing the same type of personalization features?
Since there are no comments, I thought I'd offer an inelegent but practical solution.
Leave the RequireHTTPS off in your forms authentication configuration block.
Next, you create a custom class that implements IHttpModule. This interface has an Init method that takes a HTTPApplication instance as an argument. You can then attach to the "AuthenticateRequest" event on this instance.
From here, you can 302-redirect any requests that come in without SSL when they should do. You'd probably want to drive which pages require SSL from a custom configuration section in your web.config.
To use this class for your requests, you have to add a line to the HttpModules section of the web.config.
For a start, have a look at this code project article: http://www.codeproject.com/KB/web-security/WebPageSecurity_v2.aspx - this will enable you to "step on" and "step off" of https for certain pages.
With regard to your session issues, I think you're a bit stuck. The standard forms authentication mechanism stores a cookie to identify the authenticated session which is available over http or https. My advice would be to switch to using forms authentication, and use the ProviderUserKey guid as the key for accessing your per-session data.
Hope this helps.
We have decided to not go with SSL in those few pages that required them. We looked at other web applications that did similar things and they do not use SSL. We are not really protecting anything that would be all that useful for a malicious user to go through the trouble of stealing anyways.
One option I did consider before the decision was made to remove the SSL was to store a user's session on the application's web service interface. Every page call would access the web service to access the session information. This would be enforced on every page call to ensure the session stayed active. I didn't do too much investigation into using this solution before the SSL decision was made so there could be many draw backs to this solution, especially having to make extra calls to the web service with every server hit.