System Rights Management Design __ Architecture Design

about the design of permission menu

http://blog.csdn.net/bearyb1982/article/details/2448301

Permission design (first draft)
1. Preface:
Privilege management is often an extremely complex issue, but it can be simply expressed as a logical expression that determines if the logical expression "who is doing with what (Which)" is true. For different applications, according to the actual situation of the project and the specific framework, in the maintenance, flexibility, integrity and other n more than a trade-off between the choice of a suitable solution.
2. Objectives:
Intuitive, because the system will ultimately be maintained by the end user, the right to assign intuitive and easy to understand, it is relatively important simple, including the concept of the number of simple and simple and functional simplicity. It is unrealistic to want to use a privilege system to solve all permissions problems. Design will often change the "custom" characteristics of a relatively strong part of the judgment for the business logic, and the often the same "general" features relatively strong part of the judgment as the right logic is based on this idea.
3. Status Quo:
There are generally three types of access control methods in an enterprise environment:
1. Autonomous access control methods: At present in most of the information systems in China access control module is based on the use of autonomous access control in the Access Control List (ACLs).
2. Mandatory access control method: used for multi-level security level of military applications.
3. Role-based access Control (RBAC): It is an effective method to solve the unified resource access control of large enterprises. The two notable features are: 1. Reduce the complexity of authorization management and reduce management overhead. 2. Flexibility to support the enterprise's security policy, and the changes in the enterprise has a great scalability.
4. Noun:
Coarse granularity: Represents the category level, which considers only the class of the object (the type of object), regardless of a particular instance of the object. For example, user management, create, delete, for all users alike, does not distinguish between the specific object of the operation of the instance.
Fine granularity: Represents an instance-level, where an instance of a specific object (the instance of objects) needs to be considered, and, of course, fine-grained is considered a particular instance after the coarse-grained object class is considered. For example, in contract management, list, delete, need to distinguish whether the contract instance is created by the current user.
5. Principles:
The right logic fits the business logic. That is, the privilege system aims to provide services for business logic. Considerable fine-grained permission issues are very unique and not universally meaningful, and they can be understood as part of the "business logic." For example, the requirement: "Contract resources can only be deleted by its creator, and users of the same group as the creator may modify, and all users can browse". This can be considered as a fine-grained permission problem, or as a business logic problem. Here it is a business logic problem that is not overly considered in the architecture design of the entire privilege system. Of course, the architecture of the privilege system must also be able to support such control judgments. Or, the system provides enough, but not complete, control. That is, the design principle boils down to: "The system provides only coarse-grained permissions, and fine-grained permissions are considered the responsibility of the business logic."
Permission formula: Who+what (Which) +how problem, where we implement What and part of the Which permissions problem (coarse-grained and fine-grained consistency, to a certain extent), other permissions issues left to the business logic to solve
6. Concept:
Who: the holder or principal of a privilege (Principal (owner), User, Group, role, actor, etc.)
What: The object or resource (Resource, Class) to which the permission is directed.
How: Specific permissions (privilege, forward authorization and negative authorization).
Role: is a character, with a certain number of permissions.
Operator: operation. Shows how to what.
7. Explanation:
User: In relation to role, users are just pure users, and permissions are separated. User is not directly related to the privilege, user must have the right to a certain resource, you have to associate through role. Solve the WHO problem.
Resource: Is the resources of the system, such as department news, documents, and other objects that can be provided to the user to access.
Privilege: is the resource related permission. means that the permission is bound to a particular resource instance. For example, Department news release rights, called "departmental press release rights." This indicates that the privilege is a publishing authority and a publishing authority for resources such as departmental news. Privilege is determined by the creator when it is developed. Privilege as "Delete" is an abstract noun that does not have any meaning when it is not bound to any specific Object or Resource. Publishing is a privilege for a press release, but it's pointless to just publish it. Because you don't know what the publishing object is. It is only when the release is combined with the news that the real privilege is produced. This is privilege Instance.
Role: Is the interface between coarse grained and fine-grained (business logic), a permission framework software based on coarse-grained control, the external interface should be role, the specific business implementation can directly inherit or expand the rich role of content, role is not as a user or group of specific entities, it is the interface concept, An abstract generic term.
The definition of operator includes the resource type and method concepts. That is, the concept of what and how. The reason why what and how are bound together as a operator concept rather than modeled separately is because a lot of how makes sense for a what. For example, a publishing operation has meaning for a news object, but not for a user object.
8. Thought:
The core of the authority system consists of the following three parts: 1. Create permissions, 2. Assign permissions, 3. Use permissions, and then the main participants in each part of the system are compared as follows: 1. Create authority-creator creation, 2. Assigning Permissions-Administrator assignments, 3. Using Permissions- User:
1. Creator Create privilege, Creator in the design and implementation of the system will be divided, a subsystem or called modules, what should have permissions. Here is the privilege and Resource of the object statement, and did not really connect privilege with the specific Resource instance, to form a operator.
2. The Administrator specifies the association of privilege with Resource Instance. In this step, permissions are actually associated with resource instances, resulting in operator (privilege Instance). The administrator uses the basic element of operator to create his ideal privilege model. For example, create a role, create a user group, assign a user to a user group, associate a user group with a role, and so on ... These operations are done by the Administrator.
3. User uses the permissions assigned by the Administrator to use each subsystem. The administrator is the user, in his mind has a more suitable for his management and maintenance of the rights model. As a result, programmers just answer a question, what permissions can access what resources, that is, the previous Operator. The programmer's offer of Operator means putting armor on the system. The administrator can build what he wants to do according to his wishes. The framework of permissions can be increased, deleted, and managed resource and privilege relationships. You can set the corresponding relationship between user and role roles.   (If you treat creator as the inventor of basic, the Administrator is the user of basic, he can do some scripted programming) Operator is the most critical part of the system, it is a bond, a tie between programmer,administrator,user.

Any network or stand-alone program involving multiple users with different rights will have the problem of authority management, and the MIS system is more prominent.

The following I want to say is the MIS system permission management database design and implementation, of course, these ideas can also promote applications, such as in the BBS to manage different levels of user rights.

The rights design usually includes the database design, the application Interface (API) design, the program implementation three parts.

These three parts are interdependent, inseparable, to achieve a sound authority management system, must take into account the feasibility and complexity of each link and even the implementation of efficiency.

We classify the permissions, first of all, for data access permissions, usually have input, browse, modify, delete four kinds, followed by functions, it can include such as statistics, such as all indirect data access operations, in addition, we may have some key data table some fields of access restrictions. Besides this, I can't think of another kind of permission category.

Perfect permission design should have full scalability, that is to say, the system has added new functions should not be the entire rights management system to bring greater changes, to achieve this goal, the first is the database design reasonable, followed by the application interface specification.

Let's discuss database design first. Usually we use a relational database, which does not discuss rights management based on Lotus products.

The list of permissions and related content can be described in six tables, as follows:
1 role (that is, user Group) Table: includes three fields, IDs, role names, description of the role;
2 user table: including three or more fields, ID, username, description of the user, other (such as address, telephone and other information);
3 role-User corresponding table: This table records the relationship between the user and the role, a user can belong to multiple roles, and a role group can have multiple users. Includes three fields, ID, role ID, user ID;
4 List of restricted content: This table records all the data tables, functions, and fields, including three fields, IDs, names, and descriptions, that need to be restricted by permission.
5 Permissions list: The table records all the permissions to be controlled, such as entry, modification, deletion, execution, etc., also includes three fields, ID, name, description;
6 Permissions-roles-User correspondence table: Under normal circumstances, we have the role/user has the right to make the following provisions, the role has expressly allowed permissions, all other prohibited, the user inherits the full rights of the role, in this range of permissions, in addition to the prohibition of all permitted outside the scope of the jurisdiction, except the permission to prohibit all outside. The design of the table is the focus of the Authority management, the design of a lot of ideas, can be said to be different, not to mechanically say a certain method is good. In this respect, my view is that in the personal situation, find the appropriate can solve the problem.

First is the easiest way to understand, design five fields: ID, limit content ID, permission ID, role/user type (boolean field, used to describe a record of the role or user rights), role/user ID, Permission type (boolean field, Used to describe a record to indicate whether it is allowed or forbidden)

Well, with these six tables, we know from table six that a certain role/user has/forbids some kind of permission.

Or that's enough design, we have fully implemented the required functions: the roles and users can be customized separately, but also has considerable scalability, such as the addition of new features, we only need to add one or several records can be, and the application interface also need not change, with considerable feasibility. However, in the process of implementing the program, we found that it is not very scientific to use this method, such as browsing the permissions of a user, the database needs to be repeated (or even recursive) queries, is extremely inconvenient. So we need to think of other ways. People who have used Unix systems know that the Unix file system will be divided into three kinds of operating permissions: Read, write and execute, respectively, with 1, 2, 43 code identification, the user has read and write access to the file is recorded as 3, that is 1+2. We can also solve this problem in a similar way. The initial idea is to modify the list of permissions, add a field: Identification code, for example, we can identify the entry permission to 1, browse rights identified as 2, modify the identity of the right to 4, delete the identity of 8, the execution of the rights identified as 16, so that We can easily put together the right to be divided into several records by means of the accumulation of permissions, for example, assuming that a user ID is 1, the inventory table corresponds to a restricted content ID of 2, and that the role type is 0 and the user type is 1, we can have the user input, browse, modify, The permission for deleting the inventory table is described as: 2,15,1,1.

It's really simple, isn't it. There are even more drastic ways to add a list of restricted content lists and define identifiers so that we can even use a simple record to describe the full permissions that a user has for all content. Of course, the premise of this is to limit the amount of content is small, otherwise, oh, 2 of the n-th side increment up but the quantity is amazing, not easy to parse.

On the surface, the above method is enough to achieve the function, simplify the database design and implementation of the complexity of this purpose, but there is a disadvantage, we are involved in the list of permissions is not independent but interdependent, such as modify the permissions, in fact, include browsing rights, for example, We may simply set the user's access to the inventory table for entry + Modify + DELETE (1+4+8=13), but in fact, the user has (1+2+4+8=15) permissions, that is, in this scenario, 13=15. So when we call the API to ask a user for permission to browse, we must determine whether the user has permission to modify the data table, so if you can't solidify the relationship between the permissions in the program, you can't use the application interface to make a simple decision. But this contradicts the "full scalability" of our purpose.

How to solve this problem. I thought of another way to set up an ID code, which is to use primes. We may wish to input, browse, modify, delete, execute the basic logo code as 2,3,5,7,11, when the permissions are included with each other, we set its identification code to two (or more) the product of the basic logo code, for example, you can "modify" the function of the logo code as 3*5= 15, and then multiply all the permissions to get the final permission ID value we need. So, when we ask the user if they have a certain permission, only need to decompose the final value into the quality factor, for example, we can define a user with input + Modify + Delete inventory table permissions for 2*15*7=2*3*5*7, that is to say, the user has the Inventory table entry + Browse + Modify + DELETE permissions.

Of course, on the permission list we use the above method premise is the permission list record bar number not too much and the relationship is not very complex, otherwise, just parse permission code will be machine fooled half a night:

General Rights Management Design chapter

http://sxiaomais.blog.163.com/blog/static/31741203200811102630406/

A Introduction

Because some of the system's rights management functions, although gradually improve, but always some unsatisfactory place, always want to take a moment to better think about the design of the Authority system.

Permission system has always been an indispensable part of our application system, if each application system to redesign the system's permissions to meet the needs of different system users, will waste a lot of our valuable time, so it is very meaningful to spend time to design a relatively universal permission system.

Two Design Objectives

Design a flexible, universal and convenient authority management system.

In this system, we need to control all the resources of the system, then what resources are included in the system. We can simply summarize these resources as static resources (functional operations, data columns) and dynamic resources (data), also known as Object resources and data resources, the latter is our system design and implementation of the name.

The goal of the system is to control all the object resources and data resources of the application system, such as the function menu of the application system, the buttons of each interface, the columns of the data display and the control of the permissions of various row-level data.

Three Related objects and their relationships

Probably sort out the relevant concepts of the permission system, as follows:

1. Permissions

All permissions information for the system. Permissions have a hierarchical relationship and are a tree-like structure. Let's look at an example

System Management

User Management

View User

New users

Modify User

Delete User

For each of the above permissions, there are two situations, one is accessible, the other is authorized, for example, for "View User", if the user is granted only "accessible", then he cannot assign this permission to others.

2. The user

The specific operator of the application system, the user can own the permission information, can belong to the 0~n role, can belongs to the 0~n group. His permission set is the set of permissions that he has, the permissions that each role belongs to, and the permissions that each group has. The relationship between it and the permissions, roles, and groups is N to N.

3. Role

To classify and manage many users with similar permissions, the concept of roles is defined, such as system administrators, administrators, users, visitors, and so on. A role has a hierarchical relationship that can form a tree view, and the permissions of the parent role are a combination of the permissions of itself and all of its child roles. The user of the parent role, the group of the parent role, can be pushed in the same vein.

4. Group

In order to better manage users, users are grouped into groups, referred to as users. Groups also have a hierarchical relationship and can form a tree view. In fact, we know that groups can also have their own role information, permission information. This makes me think of our QQ user group, a group can have multiple users, a user can also join multiple groups. Each group has its own permission information. For example, view a group share. QQ Group can also have their own role information, such as General group, Advanced group and so on.

For the four types of objects mentioned above, let's take a look at the relationship between them.

As you can see in the picture above, the relationship between the four is very complex, and the actual situation is more complex than this diagram, permissions, roles, groups have a superior and subordinate relationship, authority management is a more difficult problem in the application system, to design a common rights management system, the workload is really not small.

Of course, for some projects, permission issues are not so complicated. Some only need to involve the rights and users of two types of objects, only need to assign permissions to users.

In other cases, a role object, such as a role-based permission system, is introduced, where only the roles are assigned permissions, the user is subordinate to the role, and the user is not required to assign role information separately.

General Rights Management Design chapter (ii)--Database design

National day before the whole general permissions Design database Preliminary design part, now posted up.

After we have cleared up the object relationship, let's proceed to the design of the database. When the database is modeled, for n

Relationship, it is generally necessary to add an association table to indicate the relationship between the two associations. Preliminary estimate, this system needs at least 10 tables, namely: Permission table, user table, Role table, Group table, User Rights association table, with

The User Role Association table, the Role Permission Association table, the Group Permission Association table, the Group Role Association table, the Users Belong Group Association table. Of course, it may also lead to some related tables. Let's draw the tables in the PowerDesigner.

The tables and their relationships are as follows:

1. User table

User table (TUser)
Field name	Field	Type	Note
Record identification	tu_id	bigint	PK, NOT NULL
Affiliated organizations	to_id	bigint	FK, NOT NULL
Login account	Login_name	VARCHAR (64)	NOT NULL
User password	Password	VARCHAR (64)	NOT NULL
User name	Vsername	VARCHAR (64)	NOT NULL
Mobile phone number	Mobile	varchar (20)
E-Mail	Email	VARCHAR (64)
Creation time	Gen_time	Datetime	NOT NULL
Logon time	Login_time	Datetime