What is the best way of dynamic authorizing users with their roles. Indeed I have some roles that changes overtimes and currently I have this code for some of my actions or contorllers:
[Authorize(Roles = "Admin,MainFedration,FederationUser")]
public string ConfirmAccident(int? id)
{ .... }
Then if a role add or change it's permission i should search and change most of actions and roles to config new permission.
What is the best way to remove this redundant work?
The only other way would be to configure the permissions each role has in a database and then subclass AuthorizeAttribute and overload the logic for how it determines which roles are allowed by utilizing the database-stored permissions.
However, it should be noted, that this is a problem mostly because you're using roles improperly. I see this all over, even in official Microsoft documentation, which is part of the problem. Something like "Admin" is a group; roles are different and should be things like "CanEdit". A group or a user can be assigned roles, so any user in the "Admin" group, would have the role "CanEdit". Then, you don't have to change the roles config on the action because the ability to edit is the ability to edit, no matter which users or groups have it.
Maybe you should take a look at how Access Control is organized: https://nsecurity.codeplex.com/. Here's a simple solution which outlines the principles of Access Control Entries, Access Control Lists, and how access to items, subject to security restrictions is set up. This way of (dis-)allowing users' access to certain items is much like the way it is organized in, say, Windows file system.
The idea is really simple: instead of giving user permissions (not) to do this or that, the items are guarded and access is granted/denied once a simple condition is satisfied. In other words, security is not geared towards users, but towards "securables". Or, keys are used to lock/unlock doors, but not to prevent users from moving around.
Related
New at ASP.NET MVC. I am looking for some UI design ideas not entirely specific to MVC. There is probably not an exact answer but here is what I have started.
There would need to be a page with 3 tabs on it.
Permissions | Groups | Users
1) Permissions View would allow you to do CRUD operations on Permissions in a Grid
Delete on a specific permission is only allowed when the permission is not being used in any Group.
2) On Groups View, CRUD operations on Groups are allowed in grid.
Also, a Permissions link is provided that will allow to do mapping (Add/Remove) Permissions for a Group
Again, a DELETE operation on a Group is only allowed when the Group is not being used by any User.
3) On Users View, all the existing Users in the system will be presented. The grid show allow for searching a user by username, first name or last name.
Groups link should be provided for each user that when clicked allows to do mapping (Add/Remove) Groups for a User.
Below this mapping in the same view, a separate section of Permission Overrides should be provided so that a specific permission can be added with IsGranted (true/false).
Description of the database design:
1) Groups will be assigned Permissions. Based on the group that the user belongs to, User will get the Permissions.
2) UserPermissionOverrides will handle the scenario where
- a User needs to be granted certain permissions (regardless of the role they are in) or
- if certain permissions need to be revoked from a user, even if they belong to a certain group.
This will allow us good flexibility to handle the special scenarios of adding or removing specific permissions.
So, when the user logs in - 1) above will be used to retrieve the group permissions for a user and then 2) will be executed to retrieve the overrides (granted/revoked). Combining 1) and 2) will give us the final permissions for the user which will then get stored in the forms authentication cookie to prevent further database hits
Your model and functionality all make sense to me. However, I think you need to revisit the UX principles you are employing for the interface.
Write a few user stories i.e. what a user of the security system intends to do and what goal they need to fulfill for that visit.
You need not always tightly couple your UI to your model i.e. just because you have structured your model in a certain way, those entities needn't be presented as principle objects for CRUD operations to a user. It's probably very unlikely that a user of the system will come in, add a permission and leave.
Pertaining to the above, personally I would approach your user permission UI as a wizard rather than a set of tabs:
Step 1: Pick a user or add a user.
Step 2: Which roles do they need (offer the opportunity to add a role).
Step 3: In which groups do they belong (offer them to add groups here if necessary).
... or similar.
Basically, your aim should be to get your user in and out of the system as quickly as possible. I think the act of creating user stories and wizards you glean from them would be the method I would employ in the UX design of your system.
Good luck!
I've used FluentSecurity in another MVC application and its great, provides a slick implementation.
I now have a requirement to offer application wide roles, plus also provide additional permission control over individiual entities.
My application manages particular locations and a user may have permissions to perform actions at one or more locations, each location has a unique id. I'll need to check a user has a particular role for the location id (effectively adding another dimension to roles). I've got my schema mapped out, along with my repo/service layers.
I was wondering if someone has tackled this type of problem before and whether its worth me trying to solve with FluentSecurity or if I should validate the user has the role required for the location on each GET/POST request (controller or service layer).
I'm getting to achieve this in FluentSecurity I'll have to roll my own policy and capture the location id from the RequestContext.RouteData.
I haven't done exactly what you need to do, but creating a custom policy in FluentSecurity that handles your scenario should not be hard at all. If you feel it is, please let me know and I will have to fix that.
You can find more information on how to create custom policies here:
https://github.com/kristofferahl/FluentSecurity/wiki/Custom-policies
It sounds to me like you might want to split it into two custom policies. You then apply your custom policies like this:
configuration.For<SomeController>()
.AddPolicy<CustomPolicy1>()
.AddPolicy<CustomPolicy2>();
I am creating a Grails website where users will have access to the resources they create. Till here everything is clear to me. I define ROLE_USER and lock down my controllers and actions using the Config.groovy file.
The issue I am facing is that I have requirement to support group of users such that some resources created by a user can be edited/updated/deleted by other users of the same group. How do I associate a user with a "group" in spring security, what is the design/library I should use here?
What you will need to do is to have your users' roles (the authorizations) come from the database. Once that is the case, you can then easily adjust the roles a user (or set of users) has and create/remove them on the fly. The docs have some pretty good info on how to get the roles to come from the database, so I won't go any more into that here.
Once the dynamic roles are in place, however, you still need to be able to connect roles to the objects that are created. There are essentially two ways you can go about doing this:
Access Control Lists
Custom logic
Depending on the granularity you need and the flexibility you want, one option may be more appealing than another.
Access Control Lists essentially allow you to have a permission mapping between each user and each entity instance. As you can imagine, it's a fair bit of overhead and can perform poorly if you have a large number of entities and users.
Putting together your own logic, on the other hand, is much more flexible because you can set up your own scheme to connect entity instances or entity classes to users and their roles.
I dont think that spring-security provides such functionality out of the box so you will have to do that manually.
For each domain class that you this kind of functionality, store the user name of current logged in user
def authenticateService
def user = authenticateService.principal()
entity.setUser(user?.getUsername())
Then in the update/delete method of the contoller you should check if the role of the current logged in user matches
the role of the user that created the entity. If you have a match you should proceed with the update/delete otherwise throw an exception
/redirect the user to an error page
As role you can use the spring security roles or you can create a property on the user object you have created
I'm bit vague about how to start using the shiro plugin, after reading few documents. I decided against Nimble, as it comes with few tables and UI plugins.
I setup shiro plugin with wildcard realm, with my own tables. I may use permission based (rather tan role based) access control as it scales well. Now, the steps for it.
assign the permission string to the subject, and save it in the db
check the permission through isPermitted, hasPermission (or relevant tags in GSP).
Now,
1. when to use the accesscontrol through filter?
2. is there a closure injected into the controller where I can define the permission for the actions in it? I read somewhere about accessControl static closure on each controller, but not seems to be documented.
3. How do I create a typical access control scenario like only the creator of (something, a post etc) can delete it? One possibility is creating and persisting a permission string based on userid. to check the permission retrieve the object (post), get the userid and compare with subject.. seems bit complicated.. any easy implementation?
thanks a lot..
Babu.
1 when to use the access control security filter?
A. Use accessControl{true} when you want to limit access to controller actions to authenticated users.
B. Use accessControl() when you want to limit access to controller actions, regardless of parameter content, based on permissions "${controllerName}:${actionName}".
C. When you want to limit actions based on parameter content, e.g. only delete a domain object for which you have the delete permission "${name}:${id}:delete", you need to check isPermitted explicitly in the controller.
3 How do I create a typical access control scenario like only the
creator?
I would add a the necessary permission(s) to the user when the post is created, e.g. "post:${postId}:*" This way the permissions belong to users and/or roles, and not to arbitrary domain objects, as intended in the Shiro way of working. As opposed to file system permissions, which belong to files and directories instead of users.
I'm required to provide functions for both users and administrators to edit account and profile details in a web application. An example of a URL for the public side of these profiles is:
http://example.com/user/joe
I'm still torn between two ways to design these URLs. I've thought of either this:
http://example.com/user/joe/edit
Or something non-specific and separate to the profiles:
http://example.com/account
The benefit of the first one is that it allows administrators to do their job through the same functions. This avoids building a whole different backend specifically for administrators. I suppose the negative here is that I'd have to be careful with authorization and make sure nobody can edit what they are not supposed to edit.
The second is a more standard way of doing things, it'd turn out to be simpler and easier to secure, though it means a separate interface for administrative users.
What is SO's opinions on this? Are there any more pros/cons for either way? Which method would you recommend to use?
I would have a different view for the administrator with such a security sensitive area. It makes things much more explicit having a separate view. It is likely even an administrator would only be able to edit certain user information and thus have a different view to the user editing themselves.
It makes the authorization much clearer even if the two views shared a common edit form
If you are using an MVC approach, then my suggestion would be:
http://example.com/user/edit/1234
or
http://example.com/user/edit/joe
Where user is the controller, edit the controller method and 1234 or joe the user id or username respectively.
But as Gumbo commented, administrators should not be allowed to edit user information. They should have some mecanism to disable the account in case of a profile has offensive content or false info. Forcing the user to update it to get the account active again.
The way we do it is the admin and the user share the same view. Items which are admin-only are protected from editing or viewing by the user.
The reason for the single view is:
It reduces the number of 'moving parts' - when a new field is added to the user screen, it only needs to be added once,
It is easier to move items to/from the user's purview. If all of a sudden, management decides to allow a user to manage their "FizzBar" then we only need make the change in one place, and
It is easier to segregate the roles and the functions at the controller level.
I think that you should go with the second approach. It's more secure and flexible, and shouldn't be harder to code than profile editing the profile inline.