Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

8.1. Does Session State Equal Logon Session?

An architectural question that comes up time and time again with session state is whether session state can be considered equivalent to a logon session. Hopefully after reading this section, you will agree that the answer to this question is unequivocally no! When developers ask about having the concept of a logon session object in ASP.NET, not only are they looking for a convenient storage location associated with a user, but they are also usually looking for a mechanism that prevents problems such as duplicate logins. (A workaround using forms authentication for this was shown earlier in Chapter 6.)

However, in ASP.NET session state is a service that is always available on each and every page in an application. There is no concept of having to authenticate to obtain a valid session object. More important, no mechanism inside of ASP.NET enforces validity of a session identifier (that is, is the identifier a value that was originally generated by ASP.NET?). As long as a browser is able to send a well-formed session identifier to ASP.NET, and the session identifier meets some basic syntax checks, the corresponding session data is available to the application.

Contrast this with something like forms authentication, where, in the default configuration, it is next to impossible to create a forged forms authentication ticket. (You would need to guess an encryption key as well as the key used for the HMACSHA1 signature.) The problem with ...