Summary
Access control is an important part of the software security. This paper explores a method of using role and authorization to implement access control. This article focuses on access control from design to implementation.
Modeling in a field
1 security object
Limit users in a management system are "security objects". There is a feature of the security object: Once your system is designed, all of its security objects are unique. It cannot be adjusted at will (relative to user, role) during operation, so you must find and define security objects carefully during your design. The definition of security objects varies depending on the project, different security requirements are different, and should be done with customers when defining security objects.
The classification of the security object can basically start from two perspectives: classification, such as one management system can be divided into multiple subsystems, and each subsystem can be divided into multiple modules (forms, pages), each module There are also many fields; classified by behavior, such as browsing, new, modify, delete, auditing, etc. If only from an angle is unique, it is incomplete, a better method is to find the smallest structural security object to be operated by the structure, and then find out its possible operating security objects for each object. Each operational security object should be seen as a child object for the corresponding structural security object. To simplify the model we can add a rule: Operating the security objects cannot have sub-operation security objects.
2 visitors
After determining the security object, the next step is to determine who will access them, and how they are accessed. In the actual system, there will be a case where another security object method is called in the code of a secure object, but these behaviors occur in such a case where the user is in such a situation in the application session. This "situation" has a comparative term in a distributed application: context. In role-based access control systems, this context includes this user's current role in addition to the current user. This can access security objects can be user and roles, because they use unified interfaces when accessing security objects, so we can extract them out of a public parent class - visitors.
The visitor's determination is generally done by an administrator or system security when a program deployment, so it is necessary to consider its versatility and scalability during design.
3 authorization
Obviously "User-Roles" and "Accessor-Security Object" are multi-to-many relationships, so it is natural that there is a correlation object to handle these correspondence. In the Accessor-Security Objects relationship, if you want to access a security object, you can use the appropriate security object to authorize the visitor.
In the authorization mode, because the participation of the parties may have a child object. The problem herein is: whether the sub-object of the authorization automatically has the authorization (or if the child object participating in the authorization object can inherit the authorization of the parent object)? Regardless of whether to use inheritance authorization is a good answer, use inheritance can use fewer authorization to express more allowable (more convenient), without using inheritance, can clearly uniquely define authorization (more efficient).
4 verification rules
One rule hidden in the above-mentioned authorization is: Authorization only indicates allowed. In actual security management, administrators or security officers may need to grant the security object only to some of the users who have a role, and the administrator may specify an authorization only valid only at the specified time period. These are all system security rules, and the popular term is the business logic of the company. Therefore, only the simplicity of "authorization means allowed" is clearly unable to meet the increasingly complex safety needs of the current system.
We have abstract an verification rule object here. Depending on the verification rule object we can get "visitor" to access a "security object" is: Allowed, rejected, or not certain. An authorization may have more than one valid rule object, verifying each validity rule of an authorized rule has the possibility of mutual conflict. A effective rule for resolving conflicts is: refusing priority, and finally cannot be determined.
5 summary
After a simple field analysis, we can draw a more complete domain model, see Figure 1:
Figure 1 Domain model
