Two analysis design
1 static model
Security object
Since the security object is determined during the program design period, the design of the design is to ensure that there is a safe object (one correspondence) that needs to be controlled (one or one corresponds), as for the operational period related factors such as maintenance can be ignored.
A security object basically has a minimum of distinguishing between the identity (ID) of other security objects (ID) and the name of the easy-to-understand understanding (the person here means, if you use a valid coding rule when defining the number, you can save this insignificant Attributes). Because there may be a sub-security object, it must also let the user know the information about the sub-security object. We can use the Composite mode to complete the above features. as shown in picture 2:
In the foregoing, the security object has a structural security object and behavioral security object, whether it is also necessary to establish two different classes to determine this distinction? My suggestion is to suppress the impulse of subclass in the beginning of design. Because we define the objects at this time is not clear, there is still a big distance to use code. When we are dynamically modeled, we will further enrich the methods and properties of the class.
Due to the presence of a child object, it is necessary to avoid the cyclic contained in the implementation. The cycle here contains a case where b is included, and B is further included. To avoid this, you need to add a constraint in the Add () method: add () objects cannot be the current object you or on its parent object chain.
One correspondence requires a security object only one parent object, so add () is not allowed to have a security pair of parent objects (external words: now some information has such a security demand, to delegate user A and User B for the same module The same permissions, but A can only access the data generated and B can access all data. How do such security objects define?)
Figure 2: Security object model
Visitors, users and roles
According to the domain model, we will find that some characters will have a "overall-part" relationship similar to the security object. Is it also using the Composite mode? Let us analyze the source of the role: Enterprises generally define according to the production process of the company's administrative architecture or enterprise in the role of an information system. The administrative architecture has a clear level, but there is no obvious "overall-part" relationship between the roles defined according to the production (business) process. My personal experience is that the Composite mode can be introduced to represent the relationship between the role of the administrative architecture. Since these roles are managed to be similar to the user group, we can cancel the user group directly for the simplification of the model. Role is replaced. Although the model here does not strictly distinguish between the role of the administrative architecture (user group) and process-related roles, they still have fine differences in actual.
Understand the "parent-sub" relationship rather than "overall-part" to analyze the role of the administrative architecture may be clearer. When dividing these roles, you should pay attention to the role of each organization, "Department Manager" and "official" as the child character of the relevant tissue role (we tend to make greater mistakes J). The visitor model is shown in Figure 3:
Figure 3: Visitor model
Authorization and verification rules
The authorization inheritance problem has been discussed in front of the model. Use inheritance will greatly increase the complexity of permission verification, which may affect the efficiency of the verification in large systems. This is a problem that carefully considers, it is recommended to test it before practical use. Otherwise, each verification takes a few seconds, that is, the software that is better and safe will not use it.
If inheritance is used, it will naturally introduce questions about verify conflicts. For a simple example: If the user A is authorized to secure object A, the sub-security object B of the security object A is automatically has the same authorization to User A, but if the user also defines the user A Authorization 2 for security object B. In general, these two authorizations must have conflict with each other, otherwise the administrator is full of dry J. At this time, the rules of "reject priority" are not in time. According to people, they can define such rules: submission (corresponding to authorization 2) take precedence over the father-in-law (corresponding to authorization 1). That is to say, if authorization 2 clarifies that the user A is allowed or rejected, then the authorization 1 does not work; only the authentication rule in the authorization 2 cannot determine the user A to the security object B The authorization 1 will work in the case of access. A slightly careful reader will find three authorizations in the above security system: security object authorizes to the user, the security object authorizes to the role, the role is authorized to the user, see Figure 4. It can be seen that there are two "routes" in the authorization process of the security object to the user, and it is also a potential conflict source. According to "From General to Special", we let the "security object authorize to users" priority to resolve conflicts.
Figure 4 Permissions flow direction
Verify rules express the logic of the enterprise, and the logic of the company is "no logic" (many programmers who report the so-called 'metamorphosis needs', 'Unreasonable change demand' "is this). The logic of enterprises is not 'metamorphosis' is as required to adapt to the future needs of the enterprise, and what we can do is to control this change within a certain range. We should consider sufficient room for future development, and avoid falling in the future as much as possible to make a revision of the hell as much as possible. The abstract type ValidaterUle containing only one verification method is defined here, and then other meaningful verification rules to inherit this class (such as PeriodRule). The advantage is very obvious: If the customer puts forward a new verification requirement, you can add a verification class, do not change other verification classes. Here is a brief introduction to the PeriodRule, which contains a time period and one end time indicating the function of verifying, and the frequence property represents the frequency of repeated time period (daily, monthly, annual, etc.), and the validate property represents the time period Whether the authorization is valid.
Figure 5 Authorization and Verification
summary
In a further analysis of the domain model, we got a more plump model - static model. In the static model, we have added the properties and some abstract methods of each class (all types of properties here are not complete, because they don't have any relationships for the security topics we pay attention to, there is not much introduction, interested readers can Add) according to the appropriate situation). We will further improve the various methods in the next dynamic modeling.
