I'm building an web application that I want users to have specific permissions to perform a specific action. I don't want to use the default permission and role providers in ASP.NET.
I was thinking of having each User associated with a Role. Each Role is mapped to a set of Permissions (CreatePost, ReadPost, UpdatePost, DeletePost and so on).
I have a couple of questions regarding this. Would it be best to have a boolean property for each Permission on the role or some sort of bitfield? I like the idea of having methods for this but properly need to map these to the permissions stored for the role in the database.
Also, how would I implement this for each action/request? I'm thinking something along the lines of what was posted here but I'm not really sure.
Thanks!
Make your own role provider and register it in the web.config. Look at the MSDN for a sample. Once it is registered it will associate the roles you provide with the principal.
I've just done that for one of my project and it works fine.
To check whether the user has permission to execute a task you'll have to see whether the user is in the required role. In "normal" ASP.NET you will have to do this in code. In MVC you can do that with attributes on each class/method in the controller.
Related
I have an ASP.NET MVC API that serves both regular users and admin users. Admin users can do everything regular users can do plus additional functionality.
The HttpContext of requests stores user info which indicates the role of a user. Some endpoints are for use by admin users only. All other endpoints are accessible by all users. Currently, a single controller is being used for both types of user with permissions being used to restrict access accordingly.
However, I'm unsure if this is a good approach because a permission could mistakenly be assigned to the wrong role, or a developer may check the wrong permission for a new endpoint that should be for admin users only.
So, I'm considering two solutions to separate the concerns:
Add a Boolean attribute (e.g., IsAdminUseOnly) to the endpoints. This seems like a quick decision, but would cause code pollution as every endpoint that is for admin use would require true to be specified in the endpoint decorator.
Create a subclass "admin" controller that derives from the regular user controller (in a similar way to described in this question). The parent and child controllers would effectively each have a different Route (e.g., MyController and MyAdminController). The child (admin) controller would inherit all endpoints from the parent controller. Of course, role access would be specified in the child controller as described in this answer using [Authorize(Roles = RolesConvention.Administrator)] for example.
Would either of the above be a suitable solution for this problem, or are there other more suitable methods to achieve the SoC described above?
in my application i want to use the current logged in user details,
in HttpContext.User.Identity there are 'AuthenticationType', 'IsAuthenticated' and 'Name', I want some more details from database when user logged in to the system. Is there any way to extend this identity class?
As Daniel noted in his comment you're going to need to create your own implementation of IPrincipal. I'm going to assume that you're using MVC5. If so, then you're going to need to implement an authentication filter which will allow you to set the principal for the request. This authentication filter would go to the database, retrieve the fields you have added, and populate your IPrincipal implementation. Finally, you would need to globally register that filter in your FilterConfig.cs file in App_Start so that it will be applied to every controller action in the application without you having to type it over and over again.
My ASP.NET application allows users to login and access certain information from the website. These users are basically belonging to multiple roles e.g: I have roles like "Administrators", "Power Users" and "Guests". The users are allowed to modify or view data on the .aspx page as per their roles. I read through about Role Management in ASP.NET on MSN. What I could figure out is that the pages related to each role are sorted into a separate folder, i.e I need to have sub folders like "Administrators", "Power Users" and "Guests". So when a user logs in he is redirected to the pages in the role he belongs to. Am I right?
Here the drawback is that if I need to make some changes to the Administrator folder, I will as well need to make the same changes to other folders.
This would make it very cumbersome and difficult to track sometimes. Is there some other way we can do this?
Thanks & Regards,
Sarin Gopalan
Well you can manage it by separating user specific functionality into specific controller i.e. AdminController, UserController.
You can extract out functions that are not user specific into a common controller and access directly from there.
Additionally Authorize attribute can be applied on controller or even on method. It will allow you to have a fine grained control over who can access a method in a controller.
[Authorize(Roles = "ADMIN, Sales Admin")]
Is there a preferred way of doing fine grained access that can be modified during runtime?
ASP.net membership doesn't seem to support this. I thought of creating constant invisible subroles so that there would be a set of hidden roles like "_CanEditContent" and "_CanDeleteOthersContent". The check would be [Authorize(Roles = SubRoles.CanEditUser)] which would check that the user is in a role that has _CanEditUser role. The problem there is of how to assign roles to other roles so that when we create a new role like "UserAdmin" how could we assign "_CanEditUser" role to that new role? That seems impossible.
What I need to do is to be able to create roles during runtime and add custom permissions for new or existing roles I would do the checks with something like [Authorize] and custom checks for AJAX methods. How would I achieve this?
Indeed, asp.net membership does not support this. You'll have to rollout your own mechanism with your own authorization attributes, which will use information about user (or role) permissions.
You can use asp.net membership for role management, and then assign permissions to roles whichever way you want, for example, database.
I recently starting trying to use the ASP.NET 4 Membership and Role providers in my web applications. But I'm having problems implementing a good security methodology.
I understand that using web.config files we can grany or deny access to certain aspx files, but is there any good built in way to deny access to a specified Role on certain circumstances?
For example;
We have a page called "EditUser.aspx".
We have two user types; administrators and a standard users. This page is used to edit both types. However, only administrators should be able to edit other administrators.
What is the best approach to stop an authenticated user without the 'admin' role from being able to edit an administrator via EditUser.aspx?
I'm hoping for something a bit more elegant than the below:
if(editUser.IsInRole("admin") && !User.IsInRole("admin"))
{
Respone.Redirect("SomeAccessDeniedPage.aspx");
}
Thanks,
Phil
One thing to consider is to use the LoginView server control with the RoleGroups element. Maybe bind the admin users in a separate gridview and wrap that in a LoginView set to only display to users in the admin role.