I am looking into building an authentication in my ASP.NET application with the following requirements.
A user has exactly one Role (i.e. Admin, SalesManager, Sales, ....)
A role has a set of permissions to CRUD access a subset of existing objects. I.e.
"Sales has CREAD, READ, WRITE permission on object type "Products" but not DELETE"
Somehow I like the permissions to be in a hierarchy with inheritance so that I for i.e. Admin don't need to specify all available objects.
The system must quickly be able to answer the question "Does user X have permission to do Y to object Z"
All database managed (MSSQL), implemented in C#/ASP.NET
I would like to get feedback on these requirements? Any ideas how to implement this using ASP.NET framework(as much as possible)? (However, I'm also interested to know how this can be achieved without Memberships)
I think what you need to do here is implement a set of permissions query methods in either your business objects or your controller. Examples: CanRead(), CanEdit(), CanDelete()
When the page renders, it needs to query the business object and determine the users authorized capabilities and enable or disable functionality based on this information. The business object can, in turn, use Roles or additional database queries to determine the active user's permissions.
I can't think of a way to declaratively define these permissions centrally. They need to be distributed into the implementation of the functions. If you want do improve the design, however, you could use dependency injection to insert authorizers into your business objects and thus keep the implementations separate.
There's some code that uses this model in Rocky Lhotka's book. The new version isn't in Google yet.
I think one of the best implementations that I think will fulfill your requirements is documented here. The only issue is that this hooks into NHibernate, but you can use this as a template to create your own permissions implementation and simply hook into your own event model rather than that of NHibernates Interceptors.
I am working on such a system myself and will blog it once I am happy with it.
The membership API provided since ASP.NET 2.0 should suit your requirements well. The only thing I'm afraid it doesn't directly support is hierarchical roles. However you can easily use normal role based security with another manually written hierarchical roles table to achieve the required things.
You can read on how to set up ASP.NET Membership here: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
It allows you to group folders / pages etc into Groups / Users. I think you will find this sufficient!
The hiarchy is easily managed by extending the generated databases and procedures.
I would build the user/role relationship so users can have more than 1 role. I see a 1-1 relationship and I get nervous because I know that even if we don't see a need for it now, someone is someday going to want someone to be both a Sales user and a Customer Service user.
In our customer system, we use roles to layer on stuff like "delinquentCustomer." That way, the original permissions are still valid--as soon as they pay their bill. Worth considering this approach.
Related
I´ve started development on a new ASP.NET MVC-App and I want to use ASP.NET Identity 2 for user-management. I want to get rid of the role-thing because I think this is absolutely not needed, especially if I think of the way, ASP.NET Identity handle roles behind the scenes: As claims. (please correct me if I´m wrong here)
I have two information regarding this issue: This official Microsoft-Documentation points out, that one only needs to implement the features needed, if the out-of-the-box-approach not meet all requirements. The other information is, that one have to derive the custom User from Microsoft.AspNet.Identity.EntityFramework.IdentityUser. But IdentityUser implements IdentityUser<string, IdentityUserLogin, IdentityUserRole, IdentityUserClaim>, IUser, IUser<string>
From my perspective, these information are not really compatible, because if I derive from this IdentityUser, I will take all this stuff into my CustomUser-Implementation whether I need it or not.
There is one more thing I wonder about: As I understood the Identity-Architecture, there are mainly two segments: Stores and Managers. The Manager is coupled to the Application and the Store, while the Store is coupled to the Manager and the Storage.
The storage-Interfaces are as flexible as I expected. Maybe I should start here - but I still don´t know, how to create a customUser as an entity, which derives from IdentityUser, without any reference to Roles. Can anyone tell me what my problem is?
The only stackoverflow question I found regarding this issue is
here. But I won´t believe, that this is an approach to follow.
Well, first and foremost, you can't truly get rid of roles. You can choose not to use them, but you're still going to have an AspNetRoles table. There is no way to get rid of that as the role functionality is baked in. Identity is extensible in that you customize and extend the role, but the relationship is not removable. The Microsoft documentation is not wrong, here, per se; it's just perhaps not entirely clear. You don't have to implement any role-based functionality if you don't want to use roles. In other words, you don't have to create functionality to manage roles, assign roles to users, or to verify that users are in particular roles. However, that doesn't mean that the core role functionality ceases to be present in Identity: only that you may simply choose not to use it.
Second, roles are actually kind of needed, at least if you have any desire to have permission-based access controls. If every logged in user can do everything any other logged in user can, then roles are probably not necessary, but if there's any functionality that's specific to a subset of users, then you need roles. Also, roles are not claims, though they function much as claims do. Identity has a separate concept of "claims", though.
I'm writing an intranet application using MVC4 and designed as SPA application.
The application assumptions are that there is no SSO and the users will be stored at the SQL DB.
I'm not interested in open authorization with external accounts. (As demonstrated in the SPA template).
The users will have some custom fields (Mobile, Email etc.)
Most of the actions are limited to certain roles.
I'm looking for the most built-in mechanims the achieve it.
I want to use the AutorizeFilter and avoid any custom implmenetations if possible.
Mention that some of the actions are WebAPI in REST Services in the application.
I didn't find a good "end to end" article that demonstrates how to implement and manage users and roles.
Is there a template that comes with login views, models etc. and is there supporting UI for managing users and roles?
I'm using MVC 4, EF 6.0.1 amd can use the most advanced components. (No limiting legacy :-) )
Any leads will highly appreciate.
Thanks in advance!
Yaron.
In a recent similar project (MVC4, intranet, EF CF) I had a STI on the users hierarchy, and the discriminator field (which in fact is the "type" of the entity) was used to manage permissions. I made like 3-4 simple filters (like "AdminFilter", "ManagerFilter") and authorized the actions using those filters. It was really quick.
I'm looking for the most built-in mechanims the achieve it.
I've looked for something like that, but didn't find it. Well, maybe I didn't look for it that much.
I hope it will help someone...
At first I have read this great article:
http://blog.longle.net/2012/09/25/seeding-users-and-roles-with-mvc4-simplemembershipprovider-simpleroleprovider-ef5-codefirst-and-custom-user-properties
I have used simple membership and role and then used the role name as a key in an entity that extends the role with extra information.
I didn't use the Authorize filter and created custom filter that implements "Feature based authorization".
The main idea is that the authorization meachnism is a set of features.
A feature is an activity that some roles can perform while others can't.
This is a much better architecture that is easier to manage mentain and extend.
I'm going to make a small application for a business that will be used locally for scanning, and storing documents in a database located on the local machine or on a machine located in the same LAN.
I could create a table called Users with username and password and according to the usertype ID show a form, or another form. But I'm more interested in the recommended approach by seasoned programmers.
Any advice?
Edit: I'm looking for something that will be secure enough, but also extensible enough.
If it's just a simple application, don't use a spaceship to cross the road.
Create the following DB schema:
Users : username and hashed password
Roles : RoleName, RoleID, RoleStrength(int)
RolesMembership : Rolemembership table that contains userid and roleid to allow for future multiple membership.
When setting up roles, give them a numeric weight. ie: Admins = 1000, Power-users = 500, guests = 10. This way, on your forms, you can say, if user level is 500 or above, set full view, otherwise, view only or no access.
Better yet, abstract it out with a security class with methods like IsPowerUser, or IsAdmin.
It's simple, readable and reusable.
Even I cannot consider myself "seasoned", I would give my answer since I'm facing the same problem in these weeks.
I would define a permission mask in order to identify allowed operations, associate it to role groups, and then associate users to the groups. More complete is the permission mask, more granularity is allowed in the group definition.
In this way there is one permission definition for multiple users, which is better than define the role using a per-user type basis, since the permission mask can be modified and extended.
More complex schemes could be possible, which could allow per-user permission overriding group permission, or hierarchy permission masks in order to define supervisor users able to manage group permissions.
The application of these models depends by the required scalability and by the number of users of the system.
I could create a table called Users
with username and password and
according to the usertype ID show a
form, or another form.
Sounds like a reasonable way to go to me. Just remember to hash the passwords.
I would also componentize the common controls in the forms, so you can reuse the common parts.
If you are using Visual Studio, I would just use the built in Membership providers. That would take care of your database and everything automatically. No need to reinvent the wheel.
Although orientated towards ASP.NET, I'd thoroughly recommend checking out this article: https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
You can use the in-built Membership and Roles objects (even in a desktop application) to define your own schemas of privilege. Using this feature takes the hassle out of creating your own database entries for the Users (and Roles) tables, while also handling password hashing for you (leading to more secure applications).
Lastly, official MSDN articles you might want to read:
On "Membership": http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
On "Roles": http://msdn.microsoft.com/en-us/library/ff647401.aspx
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
You can try rolling your own membership or just extend is like Dave suggests.
Create your own [Users] Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.
You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.
I have an existing database with users and administrators in different tables.
I am rewriting an existing website in ASP.net and need to decide - should I merge the two tables into one users table and just have one provider, OR leave the tables separated and have two different providers.
Administrators, they need the ability to create, edit and delete users. I am thinking that the membership/profile provider way of editing users (i.e.
System.Web.Profile.ProfileBase pro = System.Web.Profile.ProfileBase.Create("User1");
pro.Initialize("User1", true);
txtEmail.Text = pro["SecondaryEmail"].ToString();
is the best way to edit users because the provider handles it? You cannot use this if you have two separate providers? (because they are both looking at different tables).
Or should I make a whole lot of methods to edit the users for the administrators?
UPDATE:
Making a custom membership provider look at both tables is fine, but then what about the profile provider? The profile provider GetPropertyValues and SetPropertyValues would be going on the same set of properties for users and admins.
Probably you should merge the two tables into one and use a RoleProvider to make the distinction between administrators and "normal" users.
Alternatively, you could implement your own, custom membership provider, which would use both tables.
Mike,
My advice is to go ahead and merge your two 'membership' tables and segregate admins from non with roles.
(This is, I know a duplicate of the previous answer but I feel the need to explain..)
In this way, unless you have some compelling reason to implement custom providers, you will be able to leverage the stock providers and database structure to provide a robust user management story for your website without writing any code (that you have to test and maintain).
.2 pesos....