Hey folks, I would like to know is there any way i can maintain stuffs like log-in,log-out,user-session..etc without using membership in ASP.NET MVC?
Faraaz.
There are three provider models concerned with the areas that you are referring to.
The MembershipProvider is concerned with authentication, validating users and storing data related to the user such as last login date, username, etc.
The RoleProvider is concerned with authorising users for particular areas of your application.
The SessionStateProvider is concerned with storing session for your application.
You can write your own custom provider for any of them if the default providers are not suitable. You could roll your own authentication, authorisation, or session management without the providers, however there would be quite a bit of work involved more so than implementing your own custom provider.
You can use the Session object to store session scoped data.
But for authentication/authorization you will need to come up with your own scheme.
You need to use the Session dictionary and a session state server. See http://msdn.microsoft.com/en-us/library/ms178581.aspx for more info.
Word of warning: In my experience the InProc session state mode only preserves the values you put into Session for the lifetime of the current HTTP request. They don't persist across requests as you might expect, even when you're using a single HTTP server and you'd think in-memory storage would persist. This may only occur while debugging using the built-in http server in VS2010, but even so it can cause you a lot of trouble trying to understand why state information isn't being saved.
Related
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...
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?
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?
This can't possibly be a unique requirement. Are there libraries already available which handle this?
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 (i.e. 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 a custom RoleProvider. The custom RoleProvider would implement GetRolesForUser by getting roles from the third party on the first call, then caching them in Cache.
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 using Claims 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!
I need to store some session related data for a user. This data does not need to be encrypted but I want to ensure the user cannot modify it. I think my options are to store it into a hidden field, store it into a cookie, or store it in ASP.Net session state. I need the solution to be server farm safe.
If its stored in a cookie or hidden field then I need a way to ensure a user can't modify it.
What do you think is the best approach for this sort of data?
First question I ask myself about session data: I really need them?
Remember that web is stateless so maybe you can re-engineering your application to not use session state.
Sessions requires a lot of management and server resources.
Meanwhile you have two solutions:
because you are in a farm put your session on SQL Server configuring session state in web.config (it requires resources and it's a bit slower but is the safest way to store session data to ensure the user cannot modify it)
add an encryption/decryption mechanism to your cookie with a private server key
A user is always able to modify cookies, because it is client-side storage. You need to store the data server-side.
ASP.NET Session State is an acceptable solution for your problem, although there are some caveats regarding server farms. This MSDN article explains how to make Session State work for your server farm environment. Be.St.'s answer touches on the suggested out-of-process approach.
A third alternative is to create a database driven session storage that does not necessarily depend on Session state. I find Session State to be a bit of a hassle with different deployment environments (e.g. server farms), so I will sometimes use this approach. You can then access this data by attaching a session key to the querystring or storing the session key in the cookie (still potentially modifiable by the user, but less likely to be a target for such action).
Personally, I reckon it's better to store the information in the cache, although you could perfectly well store it in the session or encrypt it and store it in a cookie and it's just a matter of personal preference
The reason I prefer the cache is that it is not vulnerable to Session Hijacking, so there is no possible way the user can modify it as it's stored on the server (same as session in that respect).
I asked a question about using a custom principal and I included quite a bit of code in there that might help you.
Code to store extra user information in cache: Is this Custom Principal in Base Controller ASP.NET MVC 3 terribly inefficient?
EDIT: And the reason I prefer to store this information somewhere close at hand is that I don't want to kep nipping off to the database all the time as it is very inefficient to do so.
If you need to use a farm and want to share session state among the nodes without going back to the database all the time you could use the AppFabric Session Provider. There is a bit of a learning curve setting it up but it does the job and is fast (don't run it on the same box as your application though).
I have an ASP.NET application that uses a custom MembershipProvider to allow users to log in and gain access to certain features. The MembershipProvider uses ASP.NET's built-in forms authentication to set cookies and keep track of who the user is.
Now that I've got the user logged in, what's the best way to store user-specific information for their session? In the past I've just used Session variables ie Session["ReputationLevel"] = "4230"; (my application doesn't actually have a reputation level variable, this is just an example). Is this still the best way when using a MembershipProvider? Would it be better to somehow build this information into the provider itself, or into a custom MembershipUser implementation? If I keep everything in the session, I suppose I'd have to abandon the session when the MembershipProvider indicates that the user had logged out...?
Sorry if this question is vague. I've been doing mostly ColdFusion development for the past few years, and I'm still kinda new to some of these ASP.NET technologies. I thought the MembershipProvider functionality would take care of everything I needed, but I'm now seeing there are still some holes in my implementation (in this case, where to store additional data).
This question appears to be similar, but doesn't appear to be quite what I'm asking.
If you want to persist the information beyond the session, it's probably best to store it by user in your database. There are several ways to do this:
You can roll your own by manually storing and reading in data from a SQL table as needed -- possibly using the runtime cache to save from hitting the db on every request.
You can extend MemberShipUser in your custom membership provider and add the properties to it. Here is a walkthrough...
You can use ASP.NET Profiles, which might be the easiest way to go and it supports storing data for unique unauthenticated users as well. Here's a walkthrough for profiles, although there are several more out there.
I'm not sure how you would do it, but I suppose you could extend the Membership provider to do that. But personally, I've found that ordinary sessions work just fine. Only thing I'd do is to wrap their functionality in a a set of shared functions. So your example would be:
static string GetUserReputation()
{
return Session["Reputation"].ToString();
}
and just call GetUserReputation
I've been researching this intensely for the past few days.
We're developing an ASP.Net MVC site that needs to support 100,000+ users. We'd like to keep it fast, scalable, and simple. We have our own SQL database tables for user and user_role, etc. We are not using server controls.
Given that there are no server controls, and a custom membershipProvider would need to be created, where is there any benefit left to use ASP.Net Auth/Membership?
The other alternative would seem to be to create custom code to drop a UniqueID CustomerID in a cookie and authenticate with that. Or, if we're paranoid about sniffers, we could encrypt the cookie as well.
Is there any real benefit in this scenario (MVC and customer data is in our own tables) to using the ASP.Net auth/membership framework, or is the fully custom solution a viable route?
Update: I found one person (Matt Briggs) who seems to have come to some of the same conclusions I have: This comes from this link: http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1
ASP.net membership is a poorly
engineered API that is insecure out of
the box, is not well maintained, and
gives developers a false sense of
security. Authentication is a weekend
project if you aren't building a
framework, but still, most .net
developers blindly follow the official
APIs, assuming that a major
corporation like MS can put out
something decent.
One of the first rules of creating a secure authentication system is that you shouldn't try to build the framework yourself. There are many pitfalls that can be easily overlooked. So, I would say unless there is an overwhelming reason to do otherwise, you should use an existing framework like the MembershipProvider.
To list "the benefits" requires listing all security measures that were taken by the FormsAuthentication classes which is a long list. Off the top of my head, I can think a few:
Hashes of passwords
Protection against SQL injection
Protection of the cookie that stores the authentication ticket
Use of and storage of a ticket instead of say a username in the cookie.
Checking on every page to ensure the user is authenticated
Population of the IPrincipal and IIdentity for the current user
Redirection after login (granted a feature)
Handling of failed login attempts
Locking and unlocking users
ActiveDirectory integration
Ability to easily set and change password length and complexity requirements.
Salting (from Hightechrider)
....
I wrote my own after reading through all the stored procedures in the ASP.NET Membership provider. It's not hard and you have much more control at the end of the day.
If you like XML configuration, weakly-typed strings for roles, insecure by default, random web.config files littered through your directories instead of a clean marker interface on your page classes to say 'no account required', multiple database hits for a single login, user objects that aren't loaded from your current ObjectContext/DataContext and the ability to change providers on the fly (woo hoo, who uses that?!) go for the built-in one.
If not, build your own, but if you do, make sure you add salt and encrypt your passwords, and do a proper encrypted cookie please.
Just to clear up a potential misconception, using the customer ID, encrypted or not is extremely vulnerable to sniffers. What you want to do instead is create a log in ticket at the time of successful authentication and store that ID in the cookie. This won't protect sniffers from stealing sessions, but at least the session (eventually) expires whereas the customer ID does not.
You can implement your own membership provider (as you mentioned) if you wish to have your own storage. One advantage is that you can administer memberships through IIS' .NET users configuration tool.
The biggest advantage is what the others stated already; why reinvent the wheel?
If you implement your own custom login UI using MVC you could reuse also when switching for a different membership provider.
You can customize to build your own provider. Behind the scenes the Membership provider uses the same FormsAuthentication implementation as you will write. Anyway, I have read that the main issues about the performance you will face will be related to the SQL SERVER stored procedures that retrieve the data. In one of the books about building a portal system by Omar Al Zabir he mentions some improvements to the stored procedure which can result in faster performance.
I'm porting an ASP.NET application to MVC and need to store two items relating to an authenitcated user: a list of roles and a list of visible item IDs, to determine what the user can or cannot see.
We've used WSE with a web service in the past and this made things unbelievably complex and impossible to debug properly. Now we're ditching the web service I was looking foward to drastically simplifying the solution simply to store these things in the session. A colleague suggested using the roles and membership providers but on looking into this I've found a number of problems:
a) It suffers from similar but different problems to WSE in that it has to be used in a very constrained way maing it tricky even to write tests;
b) The only caching option for the RolesProvider is based on cookies which we've rejected on security grounds;
c) It introduces no end of complications and extra unwanted baggage;
All we want to do, in a nutshell, is store two string variables in a user's session or something equivalent in a secure way and refer to them when we need to. What seems to be a ten minute job has so far taken several days of investigation and to compound the problem we have now discovered that session IDs can apparently be faked, see
http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/
I'm left thinking there is no easy way to do this very simple job, but I find that impossible to believe.
Could anyone:
a) provide simple information on how to make ASP.NET MVC sessions secure as I always believed they were?
b) suggest another simple way to store these two string variables for a logged in user's roles etc. without having to replace one complex nightmare with another as described above?
Thank you.
Storing the user's role information in a server-side session is safe providing a session cannot be hijacked. Restating this more broadly, it does not matter where user role info is stored if an authenticated session is hijacked.
I advise not putting too much faith in the article you linked to, but the 2002 vintage report linked to from your link is of interest. Here are my take-aways:
Don't accept session IDs embedded in URLs.
Focus your time on eliminating cross site scripting dangers i.e. scan all user supplied data and parse out executable java script.
Issue cookies for complete domains (e.g. myapp.mydomain.com)
Host your domain at a high class DNS operator e.g. one that only allows DNS changes from a preset remote IP address.
Don't issue persistent session cookies.
Reissue a session cookie if someone arrives at a login page with a sessionID already associated with an authenticated session.
Better still, always issue a new session cookie on successful authentication and abandon the prior session. (Can this be configured in IIS?)
The only way to make a secure cinnection is to use SSL. Anything less than that, and you simply have to make the evaluation when it's "safe enough".
A session variable works fine for storing a value, with the exception that the web server may be recycled now and then, which will cause the session to be lost. When that happens you would have to re-authenticate the user and set the session variable again.
The session variable itself is completely safe in the sense that it never leaves the server unless you specifically copy it to a response.
Have you considered setting up a custom Authorize tag in MVC. I gave an example of this in another question.
On initial authorization (sign-in screen or session start) you could seed a session value with the IP address also. Then in your custom authorization, you could also verify that IP's still match up as well. This will help make sure that someone isn't 'stealing' the person's session. Everytime you access your session data just make sure to pass the requester's IP and have some check on it.
Are you trying to control the access to functions at the client level? That is the only reason I would expose the roles and items to control client side functions.
Alternatively, you could create a function to obtain the items that the roles of the user are allowed to use, and then even if the function is called outside of the items given back to the web application, you can prevent the user from accessing them.
4Guys seems to show how to control functions with the roles.
The approach I have used in the past is to use symmetric encryption of a cookie alongside SSL. Encrypt the user information in the reponse and decrypt it in the request. I'm not claiming this is foolproof or 100% secure and I wouldn't want to do this on a banking application, but it is good enough for many purposes.
The main issue with session variables is that if you store them inProc rather than persisting them, then you need to apply 'sticky' sessions to your load balancing in a web farm environment. Guffa is correct that without this persistence session variables will occasionally be lost causing a poor user experience.
Sticky sessions can lead to uneven load balancing, perhaps reducing the value of being able to scale out.
If you are going to be be persisting the sessions so they can be accessed by all servers in your web farm, you may be better off using a Guid to identify the user, encrypting this in a cookie and retrieving the user record from your data store each time.
My obvious question is that why do you want to store a users role in session ?
Here is my answer to your query, how this helps. I have attached a small demo application for you to take a look at and understand my points. When you open this project in visual studio, click on the project tab on the top and select asp.net configuration. From the page that will show up you can do the user administration stuff.
You need to store the roles of a user in some secure manner ? The answer to this question is that there is no need for you to worry about storing the role for any user, when we have the asp.net membership, profiles and roles framework to help us out on this. All you need to do is create a role in the aspnet database and assign that role to the user.
Next you want to store two string in some secure manner. I suggest you user profile for storing user specific information. This way you have the information available to you where ever you want from the profilecommon class.
Also please see the attached demo application placed at the end of my blog http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx
Just a suggestion, you might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It has a server side implementation of the cookie whereby all cookies can be stored on the server while asp.net authentification is used to identify the user. It supports encryption and is also very flexible making it very easy to switch from one storage type to another.