I started working on a windows forms authentication project, which uses nhibernate, and has some management pages for managing user settings, such as resetting user password. This forms based authentication uses session state in order to save the user's authentication information. I will be using a special authentication attribute in order to determine whether the user has access to the application. Since the authentication method is it's own mosaic of object relational mapping code, attributes, repositories, and asp.net mvc pages, I was thinking I could run this application as it's own project on a web server, and I could use this authentication scheme for authenticating multiple applications. The only way to do this would be to save session state to the database instance and share it with the other applications. Does this sound like a correct solution? Or is there something more sophisticated I should be looking into?

Code is not really required at this point, it's just the question as to whether sharing sesssion state with other applications is the correct move, or whether I should be looking into something more sophsticated.

Additionally do other databases support session state sharing for asp.net mvc?

This is a C# asp.net mvc application. I am using nhibernate, and I have looked at some java applications. The Java way seems to be to store authentication info as a session variable, unlike entity framework/Identity framework which has some sort of cookie/Ticket setup. I don't really think there is a way to inject into the server's session state, but I could be wrong. Insights welcome.

4 Weeks
Discussion Span
Last Post by rproffitt

In my apps that used SQL databases we had the user supply their name and password for access to the SQL server. If they didn't have that, then they couldn't use the app. Also, what they could do was limited by their SQL account rights.

I guess you could weave your own security but here, we kept the security in the SQL system. Seemed easier than spreading it out into the apps.


The sql server does have a table with the user's object inside it. It's just the user is already authenticated once they pass through my page, so the other applications need to know that the user has been authenticated, hence session state. Idk is there something i am missing?

Votes + Comments
I'll answer nope. But it's your design. Here we opt for the SQL has the security (job?)

So, let me get this straight, your users, all of them on the other side of a web screen has their own database login? This seems kinda contrary to some of the technologies out there, windows forms, forms based authentication, identity framework, etc. This is a web login application. I am essentially making my own login screen via hash algorithims and I have an object relationally mapped user object with both roles and groups objects. I made an authentication attribute which I use to flag controllers, and I made a password complexity object for determining whether the user's password is strong enough. I also salted the passwords of all users in accordance to my web config file so that the hash password won't match any rainbow or brute force tables as per good crypto technique. I have heard of straight windows authentication which uses windows accounts, I have heard of identity framework for microsoft applications, and I have heard of forms based authentication where you create your own login page from scratch. Usually I believe that the application has a database login, and the users have a seperate login but I could be mistaken. Can you point me to some material for your method?


Yes, each user has their own login. How else to track down who did what to the database?

I'm not saying what you are doing is incorrect. Your design may not need such logging.

Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.