In my web application we have many users.I want to set permission for each user.In our windows application we used Database to store the Permission(Insert,Modify,delete and View).In web application can anybody tell me about where to store the permission.Somebody told that if we use database it will take so much time?In the case of XML it is easy and not taking much time.But if the client set permission for number of users,then it will create problem?....Please Give some idea
(Permission means in case of "Category" page which user can view the Category page,which user can edit information about category,which user can delete information of category,which user can add new category)
I'll leave it to the asp.net experts (one of which i most definitely are not) to recommend when to use the Asp.net Membership that Shoban suggested. I would advise, however, not to store the information in a disk file. Especially one can be user altered. You are asking for concurrency issues (especially with xml). Storing things in a database is just fine for this application. Once the overhead of the connection to the database server is handled (which probably isn't a big deal anyway because of connection pooling and is probably required by your app anyway, no?) the retrieval of info from the database is not a performance drag. So, use a database to store this info - if that database can be managed by the Asp.net Membership features the more power to you. If you want/need to roll your own, that is just fine.
-don
Take a look at ASP.net Membersip. This can help you develop your framework of storing user credentials and creating different roles. You will then have to develop your application to allow/disallow certain operations based on user's role.
Related
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 have to design a database for a application which is having millions of users.Now that website will be having multiple administrator like HRadmin,SuperAdmin,SalesAdmin.I can only have one role as Admin.
My concern is that if i handle all user related data in one table,means all users,whether admin or user,credentials will be stored in a single table,searching can be really slow for unique username and other things.
People suggested,have different pages for admin and users,add a keyword to querystring and extract it in code to find the actual admin role.
How should i implement this thing in database so that front end doesnot become bulky.I am using asp.net2.0 and sql server 2005.
Since you're using ASP.NET and SQL Server 2005, have a look at using ASP.NET Membership. There's a tool that will build out the database tables for you, and includes support for multiple users, roles, and profile fields.
Here's an extensive look at ASP.NET membership: https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx.
I agree, use an ASP.NET membership provider. You should only need to to do a look-up once when a user logs in - you can then use forms authentication to create a secure cookie that holds the authentication and roles details. So long as you have a well-indexed table, a single lookup should be quick, even if you have millions of rows.
If you will go with ASP.NET Membership - Please also read Performance Considerations for Applications Using Services
Having millions of users will require some optimization, for example we use CacheRolesInCookie as described in the article
Trust me you want only 1 user table especially if you are going to be checking for unique usernames. Proper indexing should make it work correctly. You might also want a related table that defines the roles each person has (they may have multiple roles.)
Putting keywords in the query string is a very very bad idea. If I know what keyword to use to become admin I can fake myself admin rights? If a user is logged in you can place his credentials in the session or cookie (I preffer session, because cookies can be changed on the client side), that might save you a lot of DB requests (I don't know any system that keeps updating your credentials, as far as I know even Windows caches them when you are on an Active Directory).
If you are afraid that looking up usernames in the table will take to long you should optimize your database table. Put an index on the usernames (or use it as a primary key) and you won't experience performance issues searching for usernames (also, when performing many searches on the username SQL server will try to optimize it himself).
Also using different pages might seem to speed things up, but when you need to make changes in your code you have a big problem, because you have to fix the same thing on multiple places. Sometimes re-usability and maintainability should go above speed!
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.
Our current Intranet environment is a little outdated. The current stack has ASP.NET 1.1/2.0 applications that are querying against a SQL 2000 database.
For role security, there are user groups on the servers that users are added into (so you need to be added into the group on the test and production machine). These user groups are synchronized into user roles on SQL 2000 itself. Roles are granted execute permissions to stored procedures as needed to prevent any access violations.
At the web application level, we use basic authentication (which authenticates against our Active Directory) and have identity impersonation turned on. The connection string to the database uses Integrated Security. This creates an environment where the web application connects to the database as the user logged in, which will enforce database security on stored procedures being called. It also allows us to use the typical User.IsInRole() method to perform authorization within the application itself.
There are several problems with this. The first is that only our server administrators have access to the user groups on the machine, so updating role security, or adding additional users is out of the hands of the application administrators. In addition, the only way to get the role was to call a SQL procedure called "xp_logininfo" which is locked down in SQL 2005. While I don't know the full details, our DBA tells us that this general model doesn't play nice with SQL 2005 given the nature of schemas in the newer version.
We're at the point now that we're ready to update our environment. We're writing .NET 3.5 apps to leverage more AJAX and SQL Server 2005 is the primary environment for our database. We're looking to update the security model as well to be a bit more flexible for the application administrators, and potentially leverage Active Directory more.
One concern we have as well is that a given user will most likely have access to multiple applications, so having some kind of centralized solution is optimal so we can easily remove users when needed.
What is considered the best practice for maintaining role security in this kind of environment?
ASP.NET 2.0's Membership, Roles, and Profile
I don't think the considerations related to the decisions that where made before has changed that much.
About the schema comment, those will just help you organize the database elements, so you can assign permissions to all inside a schema instead of having to configure for each procedure/table.
The decisions involved on whether having the identity flow down to the SQL Server instead of using the trusted subsytem model, are pretty much specific to the particular scenario. That said, I don't like to flow identity like that, because usually there is still logic being enforced on the application which means the sp are probably enforcing partial rules. Because of that reason, that approach also pushes to have more logic in the stored procedures.
About only administrators having access to the user groups in the machine, consider looking at ADAM (active directory application mode). I don't know if it supports integrating it with SQL Server, so I am not sure if that will work with that architecture. It is worth checking though.
Regarding not being able to get the roles, based on your info, I would assume there is a close relation between user groups and involved database roles. You can get the groups(roles) the user has in active directory.
Bottom line: evaluate how ADAM fits in your scenario, and whether the considerations involved into using the current identity flow approach remain. Also don't forget to consider the impact in the project on changing the identity flow of the application.
Try to refactor your design in such a way that your repository itself is LDAP. So essentially your users and roles objects map AD objects. You can then have the complete control rather than going through various system administrators. Of course, this is not easy depending on the state of code. But the best way to start out is to create small proof of concept to accomplish this mapping of your business objects to AD.
I am trying to achieve anonymous personalization in a ASP.net environment. I know that ASP.NET 2.0 provide Profile. However, I want to avoid traffic to the database as much as possible since the site I am working on is a relatively high traffic site.
The other obvious solution is cookie, but given the limitation of cookie, I was wondering if anyone have any efficient method to store information into cookie. Does anyone know how amazon or yahoo deals anon. personalization?
Ultimately, We are trying to serve up different dynamic content to our user base on a set of business rules outline in a pre-defined campaign. The reason is to measure conversion rate in our site. The same campaign can be use on all different pages of the site. The reason I need to set this to a cookie is that the user is able to see the same content served up previously if we want it to be. So this is what I have in cookie right now.
campaign code:page id:result display
And you can see that this will build up if there is a lot of campaign and each campaign is used on many pages.
Thanks in advance!
If database load is an issue, you can retrieve the personalization when the user starts his session on the website, and then store it on the session state. This way, only the first page load will make a call to the database.
You can store the user ID in the cookie.
Just remember to persist the session in the db when the user updates his preferences, and deleting old db records after a while might be a good idea too if that many anonymous users will visit your website.
If you want to persist the changes, such as each campaign view, there really isn't any way around accessing to write those changes. ASP.NET Membership is not bad on a high-volume site (>1 mil a day), when used correctly. For instance, you should be wrapping calls to the membership provider in a cached object, and refresh often (short expiration). Also, make sure to set the cacheRefreshInterval on the RoleProvider. This will force asp.net to cache the Roles in a cookie, to cut down on DB activity.
Another way to look at this is to take Ady's advice and to seperate the Membership into a separate DB. Yet again, another great feature of the ASP.NET Membership provider - you can set a different SQL connection string, and load it up on a different DB and/or server.
There are several other techniques around the membership provider that can really increase performance. Some quick google searches comes up a number of them.
I'd create a database record for the visitor and only store the ID in the cookie, this way you can look up all the personalised details from the database, and keep the cookie size to a minimum.
If database speed is an issue, perhaps use a differrent database and server to store the personalisations.
Alternativly you could store personal data in the file system, and load into the session when the visitor returns matching the cookie ID.
If identifying the user and cookie clearing is an issue, you cold use and ActiveX control, but this requires installation on the client computer, which people could object to.