I described the basic practice of using AOP separation rights in Yesterday. Going home carefully thinking about it, adding the results of thinking.
We know that there is a basic (interface) object in the basic RBAC model: Domain, Group, User, Role, Privilege, Operation, Resource, and Outside SECURITYMANAGER. Privilege is generated by Operate Resource, and Role corresponds to several Privilege. Different Domain, Group, User have different quantities of Role, where User's Role can inherit from Group, or inherit from Domain; privileges can inherit from Domain. When performing external performance, it can be judged simply by the return value True / False of SecurityMananger.checkpermission (User, Privilege). Each object above is an interface. SecurityManager can be injected in reverse through IOC, so that this permissions model is more flexible.
In actual conditions, the definition method of Resource in this permission system is the most difficult to control. There may be different definitions in different business systems. And this way is very inconvenient. Taking an ordinary "research project management" project as an example: something required to control permission control may be: user information (add-to-hand refueling), project information (increasing refund), log information (view, statistics), etc. Control of this permission If you write in a vertical programming, you need to do the following:
Research: What is the resources needed to control? User Info? Project information? How do these things express? This problem is difficult to consider in this model. The final result is often, using a rights model without a resource interface, forming a new document: permission code and corresponding instructions. Each programmer needs to refer to this table when writing the appropriate business logic, and adds a sequence of IF --- else to determine the permissions. This practice is undoubtedly dangerous. Because the permission code changes, this business method is rewritten immediately. Slightly thinking that it is not difficult to know, this method is not available at all: even the URI-based solution is not as good.
It can be seen that it is a business object like user information, project information, and the like, which is understandable for people, but these business objects are unreasonable as the resources in RBAC. So I propose a new resource concept: the specific business class, business method as resources in the RBAC model. This will be able to really get rid of permissions and business logic. The specific approach is to store all business method names and corresponding role names into XML files or databases to form a resource library:
Method role ---------------------------------------- UserManager. * UserManageruserManager.Update UserManagerUserManager.Update UserLoginfo.view * loginfo.statistics logmanager ...--------------------------------- ---------
The judgment of permissions can be performed in the specific implementation of RBAC. Here, it is assumed that there is a method of securityManager.checkpermission (user, privilege) (here the Privilege actually does not perform a specific business method). According to this method, a production Aspect: (! SecurityManager.checkPermission (User, Privilege)) public class PermissionCheckAdvice implements MethodBeforeAdvice {public void before (Method arg0, Object [] arg1, Object arg2) throws Throwable {if {throws new PermissionDeniedException (User , Privilege);}}}
Then use AOP to apply this Advice to all business methods (classes, or methods) may have a certain regular meaning in a Package with universal meaning), and intercept all permissiondeniedException:
Public Class PermissionthRowSadvice Implements Throwsadvice {Public Void AfTHROWING (Method Method, Object [] args, object target, throwable subclass {// The permission Denied Exception makes your own processing. }
}
For a corresponding Spring Beans configuration, please refer to my last Blog.
AOP Separation Permissions Focus on this is as follows, some is more important but not, how to introduce, how to get the context environment, etc., you may need to do it yourself. It is proposed here that a concept of making Method as a resource, and I hope to help the colleagues that do the permission system.
My blog: http://www.Webuc.Net/Mechiland
