会话身份验证等同于 FormsAuthentication？

Question

I'm using a login form to authenticate users.

FormsAuthentication is right out as it stores sensitive user/role membership in either client-side in a cookie or within the URL. Within the URL is a huge security risk, so I won't even get into that. With the FormsAuthentication cookie, this creates problems with a) security where the client is in the position of dictating it's own roles; and b) way too much data stored in cookies. Since I'm gaining nothing through security and loosing out big time on the size of user data storage, I'd rather just work with Sessions.

I'd like to reuse something like FormsAuthentication for all its basic login form-handling features. But i would rather have it store user data server-side in perhaps Session rather than client-side all stuffed into a single cookie. I'd rather just authenticate against a Session token of some sort.

I have no database and local disk storage of user data is forbidden. I rely on a 3rd party authentication service provider, and a requirement is that I must reduce chatter with this service. Thus, sessions for temporary storage of user info. Sucks, but that's not necessarily the problem I'm asking about. Also, a requirement is that I must set/use HttpContext.user and likely Thread.CurrentPrincipal for use later on in such things as AuthorizeAttribute, for displaying user info in views, etc.

So FormsAuthentication stores all user data client-side in a cookie. Whereas Session stores all data server-side and just relies on a simple client-side token cookie. However, Session is not available anywhere during the asp.net startup and authentication steps. Is there an equivalent forms "membership" provider that stores all data in Session server-side instead of client-side?

If there is no Session equivalent...

1. Where do I set HttpContext.user and Thread.CurrentPrincipal to make both values available throughout the rest of both MVC apps without interfering or messing up other MVC components?
2. Hinging on #1, is Session available at that entry point? If not, how do I make it available so I can create the Principle/Identity object using the data stored in Session?
3. This can't possibly be a unique requirement. Are there libraries already available which handle this?

Answer 1

Session stores information in a client-side cookie too! (or in the URL if cookieless).

If you want to authenticate a client, he'll have to provide some kind of credentials - usually an encrypted token in a cookie once he has logged on. If not a cookie, then what do you propose?

You should use FormsAuthentication. The sensitive information stored in a client-side cookie is encrypted using a key that should only be known to the web server. "the encryption methods being public knowledge" doesn't mean that you can decrypt the data without access to the appropriate cryptographic key.

You mention "roles" and a "third-party authentication provider". If your third party is also providing roles (ie an "authorization provider" as well as an "authentication provider"), then it would be reasonable to cache roles obtained from the provider on the server. Session is not available when a request is being authorized, so the best solution is to use the Cache (System.Web.Caching.Cache).

Personally I would encapsulate this in acustom RoleProvider . The custom RoleProvider would implement GetRolesForUser by getting roles from the third party on the first call, then caching them in Cache.

Answer 2

Not sure if I like what I'm about to suggest, but you could do the following:

• Leverage the Application State or System.Cache as a global storage for user credentials.

• Use an InMemory database (like RavenDb) which can also have encryption (in memory, I believe).

  Using the Application state as a place to storage relatively common / frequent stuff I think is not a great place because of

  • Scaling / locking issues? <-- just a gut feeling.
  • Permenant data? so you have users in the website's memory .. then the website crashes or recycles, etc... what happens now to that data?
  • RavenDb is awesomeballs - go.use.it.now.

I understand that you are not storing anything locally, so whenever a user hits your system, you need to refresh your inmemory cache, etc. Fine. A pain in the f'ing butt , but fine none-the-less. (EDIT: unless the data has been cached in memory .. that is)

Anywys, two suggestions.

ProTip:

Oh! move away from role based shiz and start usingClaims based identity stuff. Yes, it still works with IPrincipal and HttpContext.User, etc. So all previous code is NOT busted. But now it's baked into .NET 4.5

Awesome Video on this for you, me, everyone !

Finally - bonus suggestion

A nice package that auth's with either Facebook/Google/Twitter. You said you're keeping the user cred's on another site (good move!). If you're using other providers, then stick with DNOA or SS.

GL!