In the software system, the permissions refer to the permission of the system user's execution of the system object.
I. What factors affect
Figure 1 Factors related to object authority
From the definition of permissions, the permissions are related to the system user, the system object, in general, the system user is not directly associated with the permissions, but is indirectly associated with the role. Related factors for authority may be:
1. Role authorization (permission table)
For example, user A grants the role B read permissions to the system object C.
2. Special roles (such as administrators) have special permissions for the category of certain system objects
For example, the system administrator has all permissions to all objects in the system. Sometimes not all objects, but a category object, such as all permissions for user objects, but there is no special permission to other objects.
3. Internal status or attribute of system object
For example, the owner of the file has all permissions on the file, and the file is only the permission of the user when the file is locked by a user.
Second, the implementation of authority mechanism
Figure 2 Class diagram of the system object part
In the system object part, it is mainly based on permission judgment relating to system object relationship, such as permission table (different system objects may have different permission tables, so put it here to handle it in the role part), and some System internal status or attribute related permission check (because different system objects and privileges can be different, so you should be processed here. If it is a relatively universal permission check, such as checking system objects and roles. Owner The relationship can be used as an external Permissioncheck class; if it is dedicated or a permission check for the internal state or attribute of the system, it can be considered as an internal class). The PermissionCheck here is a policy mode to handle permission issues. The permissions here is not enforced to use this mode. The system object can completely do not rely on any permissioncheck to process permissions. The benefits of using Permissioncheck are simplified system objects, and some universal permissionchecks can be implemented to reuse, PermissionTable is also an implementation of Permissioncheck, basically can be used in all system objects.
Figure 3 Class diagram of the character part of Figure 3
The permivation mechanism of the role part is based on the following: One is based on the permission assignment of the system object is role; the other is that each system user corresponds to a corresponding proprietary role (this role can not participate in the authorization, but The user represents the user when the permission check is to determine the relationship between itself and the system user). The main responsibility of the system user here is to find which roles they belong to, and request these roles to determine the permissions of the system object and combine them. Due to the complexity and variability of the organization structure map, the responsibility of this combination role permission is placed in the role part than placed in the system object part. Once the organization of the organization changes, it will not affect the system object part (except The system is classified as only two types and normal, and the combined permissions must also consider this, which is also put in the system user to handle more reasonable). In addition to requesting system object judgment permissions, each role is to process special permissions related to role, such as system administrator roles, document administrator roles, etc.
Figure 4 shows a collaboration diagram for checking the system user USER for the permissions of the system object systemObject if the authority type permissionType is.
Figure 4 Collaboration of the permissions
