Member Avatar for overwraith

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.

  • 2 Contributors
  • 4 Replies
  • 767 Views
  • 23 Hours Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

Short answer: centralize the authentication service, but avoid using shared server-side session as your SSO mechanism.

You can run a single authentication app (good idea) and have other apps rely on it, but storing the auth state in a shared ASP.NET session (SQL/Redis) is brittle. Session state is transient, tied to a session id cookie (ASP.NET_SessionId) and not designed for multi-application SSO. That approach creates coupling, makes revocation and scaling awkward, and is easy to break with cookie/path/domain issues.

Two practical, safer options:

  • Share the authentication cookie: if all apps are under a common parent domain, issue a single auth ticket/cookie that every app can read. In classic ASP.NET that requires identical machineKey and the same cookie name/domain; with OWIN/ASP.NET Identity or ASP.NET Core you must share the data-protection key ring. Also harden cookies (Secure, HttpOnly, correct SameSite) and implement a server-side revocation mechanism.
  • Use a standards-based identity service (recommended for long term): build a small IdP using OpenID Connect / OAuth2 (or use a hosted provider). Apps redirect to the auth server, get a token or id token, and validate claims locally. This scales across platforms, supports MFA and centralized policy, and keeps your NHibernate user store usable by implementing a custom Identity store or letting the IdP talk to your user DB.

About ’s point: giving each user a SQL login is a valid pattern when DB-level auditing/permissions are required, but it is heavier operationally and orthogonal to app-level SSO. Use session state providers (SQL/Redis) when you need a distributed session for a single app across a farm — not as a primary SSO mechanism.

If you want a quick win and all apps share a domain/platform, try the shared-cookie route first. If you need cross-domain, multi-platform, or future-proofing, invest in an OIDC/OAuth2 identity service. Troubleshooting checklist: identical crypto keys, matching cookie settings, clock sync, and test modern browser SameSite behavior.

Recommended Answers

All 4 Replies

Member Avatar for 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.

Member Avatar for overwraith

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?

commented: I'll answer nope. But it's your design. Here we opt for the SQL has the security (job?) +15
Member Avatar for overwraith

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?

Member Avatar for rproffitt

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.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.