I have a website that's sort of a Craiglist type app.
In my Database, should I create a table called UserRoles, and assign the UserRoleID as a Foreign Key to every user created? 1 for Admin(Complete Priveledges), 2 for Moderator, 3 for Normal User, etc.
Also, inside of my ASP.Net application, say I have a UserControl. Inside of that user controls method, should I ask if User.ID = "1" make a button X.Visible = True?
Say if the currently logged in user is an Admin, make a little red X appear so the Admin can easily delete a listing, etc.
Or is there a more established way to do this?
You have the right general idea of a roles provider there. Role providers give a user some level (or perhaps multiple levels) and then in your code you can validate the current user's level when displaying content and evaluating inputs.
If you are using your own system then what you have described above is a perfectly reasonable approach to authentication and authorization. However, if you are using the ASP.NET built-in MemberShipProvider and RoleProvider (which you probably should be!) then there are many tutorials on getting those up and running. Personally, I would recommend using an existing provider over reinventing the wheel, but that's just me. You'll find that the built in providers are very comprehensive and simple to use.
Roughly speaking that is how you would do it.
You should probably take a look at .Net Membership as it already provides most of the leg work to get this done.
Also rather than writing user.RoleID == 1, all over the place consider writing some methods/properties to answer the question for you.
e.g.
if(myuser.IsAdmin)
{
....
}
or
if(myuser.HasRightsTo(Rights.DoX))
{
....
}
ASP.NET 2.0 introduced Membership. It makes maintaining users, roles, and profiles rather simple. I would recommend using the default SQL implementations.
Related
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 was wondering (and I know it depends on the project and what not) what is the best/proper way of developing a custom access table where the admin can fine grain access to the site. Is it basically creating a bunch of roles dynamically and checking for those roles using the [Authorize] attribute? one problem I see with this (and I might be wrong since I just started learning the asp.net MVC architecture) is that in order to modify access I would have to change and recompile the whole site.
What I'm looking for is to present the admin with a set of actions and have them pick and choose what each user (and/or role, where role can be something different than the simplemembership roles if that would be better) can and can not do in the site (anywhere from accessing a particular action to making a change to the name property of entity1 for example)
Anyone has a suggestion of a tutorial or some sort of plugin or even a way I can achieve this?
You have misunderstood the authorization pattern: upon authentication a users id AND her assigned roles are to be attached to the thread context in an iprincipal. This principal is then checked against your software when you do security checks in your code.
There is therefore nothing that needs to get recompiled, unless you want to change which roles are allowed to do what. And then only for the places you have done programmatic checks. Access to url paths can be defined in the web.config.
I have an existing ASP.NET MVC application that is working well. It provides a select group of people with a set of management functionality. I am now tasked with allowing a much larger group access to a very limited portion of the exact same application.
Is an ASP.NET MVC Area the way to do this? The reason I ask is because I would like to have all users visit the same web page (mysite.com for example) and I would like the look and feel to remain the same (take advantage of the same master page files or _Layout.cshtml).
The current setup, is that all users have equal access (full) to all data the system presents.
So when Bob goes to
/People/Index
he sees everything, and when Sally does, she sees the same thing.
Now I need to allow a bunch more individuals to access this same thing. So when Cindy goes to
/People/Index
All she will see are people who report directly to her, and the same for Dave, and everyone else who is not specifically part of the "admin" group who get full access to everything.
The uri here, is not important to me; but what I do want to do is be able to recycle the same layouts and views, while using a different set of controllers (which have additional business logic to only show the subset of data).
Is an ASP.NET MVC Area the correct way to do this? If not, a pointer in the right direction?
If the only requirement is that the data be limited to those people/items directly related to the user, I would do this in your data tier. When you go to load the list of users, return only the users Cindy has access to. Perhaps have a user-table flag for whether the user is an admin user or not.
public IEnumerable<User> GetUsers(User requestingUser)
{
if(requestingUser.IsAdmin) // return your full list of users
return // list of users filtered by reporting to requestingUser
}
If you do all this logic in your data layer, the users all use the same site and go through the same page-flow, just what displays in the pages is limited. Of course you could also test the user's admin flag when rendering certain parts of views as well, etc.
I think that you are on a good Track with ASP MVC something you want to look it to is to implement roles in your application and based on roles present certain information to the user if the user do the same functionality I would not go with areas if I understand your question correctly you are not developing different aspect under the same app like Blog, Shopping and so on which have totally different functionality please look at Roles and Memberships
http://www.asp.net/web-forms/videos/how-do-i/how-do-i-secure-my-site-using-membership-and-roles
I'm building a new website and a friend suggest to me to use the asp.net membership for the authentication process (login, registration, password recovery, etc..).
I saw that everything is stored in an XML file.
I would like to know what are the pros and cons using the membership instead of to build something from scratch.
The MS login solution consists of several parts.
Authentication - "Who can access your site"
Forms Authentication - This basically creates a secure cookie that says "I'm authenticated!" on every request. Without this, users would have to log in every single page.
Pros: This works well
Cons: None - use it
Membership - This is how you store your users and their passwords, and validate user credentials. There are several ways to approach this:
Using the SqlMembershipProvider - Microsoft gives you a database to store users/passwords in securely, and gives you a way to authenticate credentials.
Pros:
Less/no custom code to maintain. Works "out of the box"
Works with Membership controls and API
Cons:
You have to use a Sql Server and use their database schema. (not a problem IMO)
No control over how passwords are initially generated. They're long and ugly
Steeper learning curve as you get familiar with the technology
Creating a custom MembershipProvider - You can inherit from MembershipProvider to customize where and how you store your data.
Pros:
You get Encryption/Decryption of passwords for free
Control over where you store your users and what the data looks like
You can still use the Membership controls and API
Cons:
Have to implement your own storage solution
You have to write, debug, and maintain a lot of custom code
If you add additional functionality, you have to cast the provider to use it
Creating your own Authentication scheme
Pros: Complete control
Cons:
You create everything, but have to debug/maintain everything.
You have to control security over credentials yourself.
Can't use Membership controls (This isn't a big loss as the controls are pretty simple to replicate)
Can't use Membership API
Authorization - "What can the users do?"
Roles - Roles control what the users can do via the authorization mechanism provided by the web.config and also works with security trimming on the sitemap.
Using the SqlRoleProvider - Microsoft gives you a database to store roles
Pros:
Works with the web.config
You can assign more than one role to a user
Cons:
Roles are just a string, no "hierarchy of permissions" support. This can make it difficult to create rules around which users can edit other users.
Creating a custom RoleProvider - You can inherit from RoleProvider to customize where and how you store your data.
Pros: Works with the web.config
Cons:
Have to implement your own storage solution
Still just a string and are as limited as the previous solution
If you don't implement it correctly, it could do a lot of database calls.
Creating your own Authentication scheme
Pros: Complete control - Just do custom checks on your page and error/redirect as necessary
Cons:
Doesn't work with the authorization mechanism provided by the web.config / sitemap. Practically this means that adding a page to a folder (such as /Admin) no longer guarantees security on that page.
It's important to note that the Membership and Role providers can be chosen or customized independently of each other. I would personally recommend using the SqlMembershipProvider if you can and evaluating your options for the Role Provider.
I dont like to use Membership Provider.
This is util when the scenario is "standard", but in cases that you need more custom rules, I think that dont works well. Appear "workarounds".
And not need store in a XML, exists another solutions (database, for exmaple).
Cons:
Your preferred datastore might not be fully supported out of the box
It might not match your current or future requirements
You might not fully understand the intricacies of how it works (over something you built yourself)
Pros:
You might save time compared to rolling your own.
Personally... if this is a serious project I would roll your own (but of course keep forms authentication). In my experience a lot of these 'out of the box' features from MS are rather half-assed.
The nice thing about ASP.Net Membership is that you can use as much or as little as you like - you can store user data in various forms (as others have mentioned), or you can just use ASP.Net Membership to handle session authorisation and page protection.
For example, you can go the whole hog and use the login control, the SQLMembershipProvider back end and just let ASP.Net Membership do everything end to end.
Or you can store your own usernames and passwords, in your own database table, authenticate the supplied details yourself and then simply just use "FormsAuthentication.RedirectFromLoginPage()" to tell ASP.Net membership that the user is authenticated, and have ASP.Net Membership then control access to pages.
ASP.Net Membership is tried and tested, its used by thousands of sites inside and outside of Microsoft, so you know the code works and works well. If there is an issue, then there are many implementations out there that will find it. Your own approach just has one user...
Actually, everything is not nessicarily stored in an XML-file. You can store the membershipdata in several ways, including a database.
You can also use the ASP.NET roles/membership library as a starting point for rolling your own. There are a few tutorials on doing this around the interwebs.
The pros with using the built-in functions is that the ASP.NET membership gui-controls more or less "just work".. ;)
In my opinion, the .NET membership providers are a great way to go regardless. I have written quite a few large applications using them. If your architecture is good, it's fairly simple to add functionality and change data in future releases.
Here's a bit of context to frame my answers. The membership/role/profile solutions in .NET consist of two parts: the framework and the providers. The framework consists of the methods and information your program will interact with. The providers determine how the data will be stored.
I find that the framework is excellent. There isn't much that you can't do regardless of how you want to interact with it. The default implementations do give you a lot for free. Any lack of functionality is further mitigated as a con if you are using good coding practices. See the starter ASP.NET MVC application for an excellent example of wrapping the membership framework.
The data never seems to work out the way you want, but it's nothing you can't work around. First as folks said, there are a bunch of providers shipped with .NET. And this is also where implementing your own provider comes into play. We usually start by subclassing SqlMembershipProvider. If something doesn't work the way we want, we override it. And changing the data tables at a later time if needed is not terribly difficult.
Using what already exists always seems to let us get going quickly and adapt as needed. In truth changes to this code don't happen often. Using the Microsoft solution at the beginning might not result with the prettiest piece of work, but it gets the job done quickly and lets you move on to solving important problems.
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.