I have a web application which requires two types of users, well 3 but the third one doesn't require a role: Admins which can access every page including the admin page which allows control over members; Members which can access every page except the admin page and they can post their data (high scores of a game); and guests which can visit all pages except the admin page and they can't do anything really.
Looking around I found out that ASP.NET has roles but they are tied to only three types of role providers(SqlRoleProvider, WindowsTokenRoleProvider, and AuthorizationStoreRoleProvider). Also I'm unsure but I assume that ASP.NET's Roles are connected to the whole Membership thing which means that unless I use the ASPNETDB.mdb database everything fails.
Anyway I have to restrict everyone but the admins from entrance to the admin page and allow members to post their scores. The idea I have now is that upon login, when I authenticate the user I store the user role into the cookiless session data and read it on every page load and proceed accordingly. Is there a better way?
Asp.net membership is not tied to a DB, you can roll your own, but I am assuming that you will be storing your users in a database of some sort, so the SqlProfileProvider is probably sufficent (this can be any database, does not need to be ASPNETDB.mdb).
Details on adding this support to existing DB is here: Create ASP.Net membership database structure in existing database
You will need something like the membership, as you will need to login, you need roles, and this is what the membership API is all about. It also uses industry standard storage etc., so that you don't code yourself a security hole by rolling it yourself.
You can then restrict either individual pages, or more commonly entire folders (e.g. an admin folder) by role using web.config files.
Well, it doesn't really matter how you call your database as long as you register the membership and roles services in your own database. It is as simple as running the aspnet_regsql command prompt tool without any parameters whatsoever and it will launch a wizard (.net style) to guide you through the installation of these services. ALL it does is create sql server objects in the database you wish (schemas, tables, sprocs, etc)
Now, if you dont like these built in providers (particularly I don't) there's nothing stopping you from implementing your own, it's quite simple but maybe a lengthy process due to the amount of abstract or virtual methods you'll need to implement/override depending on your approach or need. You two options to implement your own...
one is implementing theRoleProvider abstract abstract class or
extend/inherit from the SqlRoleProvider class which exposes a lot of virtual methods and properties.
Related
I'm using the out of the box Asp.Net Membership functionality to handle my user management and role management.
My application consists of a single database for each client and each database has its own Membership provider and role provider.
However, there are some users who work for more than one of the clients and I want to be use a single login and let them choose which client to view. I have everything setup to facilitate this "client switching" by using an intermediate database that stores all usernames and a relation to which clients they have access to. I also have it setup so any updates to a user in one database will update all of the corresponding users in the other databases. All of this logic is working very well, except that I can't seem to figure out how to tell ASP.Net to change to a specific MembershipProvider and use that one.
The process I thought I should use is as follows (when the user switches the client in the clients dropdown):
Log the current user out
Tell ASP.Net which Membership provider to use (selected based on the client chosen in the dropdown)
Log the current user in using the selected client's membership provider and refresh/redirect to the page they were viewing when they changed the dropdown
I know how to get a reference to the specific membership provider (Membership.Providers[MembershipProviderName]), but I can't find any information on how to tell ASP.Net to change its membership provider. I'm not really even sure how the asp.net Login control does this in the background either - something that would probably help me out in all of this.
I've been searching SO and the web for awhile and can't seem to find much about doing this other than a few threads where people are trying to modify the DefaultProvider attribute of the Providers element in their Web.config.
This MSDN tutorial may help you.
I have an asp.net application that uses the SQL membership provider. I know how to get multiple applications using the same membership provider so a user can go to multiple sites and login using the same credentials. However the requirement on my current project is that each user is given access only to certain applications. For example, the user is given credentials to access Site 1, then at some point in the future, the user needs access to Site 2 and a manager/admin has to allow the user to access Site 2. Or when the manager creates the user's account initially, he/she approves access to the 3 sites (or whatever) the user needs to access.
So my question is what is the best way to use 1 membership provider for many applications, but only allows users to access applications they're approved for (so a manager can manage access to applications, but give users 1 username and password)? I've thought about using roles, but I already use roles in the application for allowing access to certain features in the application. It seems like that would get messy.
I've read about 50 similar questions on SO but none of them addressed the application approval requirement. Thanks in advance.
The easiest straight forward method here is to use roles.
If you add more roles (one for each app) for this purpose it is no big deal. You have a basic role for each app that must be available and check this on Application_AuthenticateRequest or Application_AuthorizeRequest . There are other ways to do it, but this is the least impact, easiest to code (nothing required but a role check), and easy to follow.
I’ve been asked to upgrade a few applications and I’m planning on merging all of them into one asp.net application. I’m fine with this decision and have spoken with fellow workers and they also think it’s the best option to go with.
The application will be accessed from a small group of users which belong to a larger domain. I’m currently planning on using Windows authentication and only allow this small set of users to access the asp.net application. Also there must be some role management, so that only certain users can view certain functionality.
I really don’t want to have many different windows groups; so I want to avoid having to assign different windows groups to different folders and control permissions in the web.config.
What I’d like to do is:
- Assign one windows group to the small group of users who will access the page.
- Create a custom membership provider and control the user who accesses the application. Depending on the user I will then assign his current set of roles.
- Add an application setting to the web.config, with the name of the current administrator, so if he logs in, he will be assigned all roles, and will be able to create and assign roles to other users.
I’d appreciate some advice if this would be the correct way to go about this.
Thanks!
I would check out the AccountManagement Namespace.
I like to use this. You can create a global security group (one for each 'role'). The account management namespace will allow you to fetch the UserPrincipal from AD with their logon name from the http context. Then you can check them for memebership in the security groups you created using the .IsMemberOf Method.
I'm working on a project that needs to authenticate users based on records in two different databases. All administrators are stored locally and require full functionality to manage their accounts (reset password, etc). Regular users are authenticated against a different database used by another web app, so I only need to check that their credentials are correct.
After entering their username/pass at the logon screen, my app should check if they exist in the local admins table. If so, they are given the role of 'admin' and allowed access. If not, it should then check the other app's user table and give them a 'user' role if successful.
The project is basically a large online book. Users simply need authentication to view it, rate the sections, and bookmark pages. The rating/bookmark data will be associated with their unique id. All user management is handled in the external app. Admins, however, will only be able to view/edit the pages and will NOT be rating/bookmarking things. Their accounts will be managed with this admin area.
What is the best way to accomplish this in a .NET MVC application? By 'this', I mean integrating the logon/authentication system with both and assigning them a role based on which database confirms their credentials.
Thanks in advance!
MVC really doesn't have much to do with your user validation logic - you'll need to implement a custom membership provider to handle connecting to both databases and performing the validation. This membership class could be ported to any application though, it's not specific to MVC.
Once you've got your logic in your custom membership provider, you just need to use FormsAuthentication with your MVC app, of which there are lots of tutorials around, here's a quick one.
The only tip that I would add that pertains to MVC is that you should try to keep your logic for view decisions in your controllers. It's tempting to put something like "<% if user == admin then renderPartial(this) else renderPartial(that) %>" in your View, but that violates MVC principles in my opinion. Much better to use ViewModels or populate ViewData in your controller.
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!