Introduction to rbac principles and analysis of Kasai

First, an Administrators Group has the root permission "/Kasai/" and the root permission. In terms of permission allocation, group, role, and user all have their own root nodes: "/Kasai/group/", "/Kasai/role/", and "/Kasai/user/". The newly added group, role, or user will be expanded under this node. Because the user's permissions are extended under the "/Kasai/user/" node, it is doomed that users created under normal circumstances cannot obtain operation permissions for users (such: create a user. To solve this problem, the Kasai Development Team introduced a Super User concept when developing the Kasai system, expanded the kasai_users table, and added an ID field to represent a Super User, for super users, the system no longer makes tedious permission judgments and allows all operations to be performed directly.

Kasai uses an open source encryption algorithm-jasypt Encryption Algorithm for user passwords. This Java package provides developers with a simple way to add encryption functions for projects, including: Digest password authentication, text and object encryption, integrated with Hibernate and spring Security (acegi) to enhance password management. Jasypt complies with the RSA standard and provides one-way and two-way encryption technology to protect users' passwords more securely and support binary encryption. jasypt can encrypt objects, files, and numbers as needed, apart from text and binaries, jasypt can also be classified and encrypted with numeric values (biginteger, bigdecimal or other types). It supports hibernate persistent encryption and secure threads, provides non-configured encryption tools and flexible configuration, defines domain encryption in the hibernate ing file, seamlessly integrates with spring applications, and spring Security (acegi Security) option integration is suitable for executing password encryption and matching tasks. By using a secure password encryption mechanism and providing higher configuration and control, the security of user passwords is improved, it is more intentionally thought that for the same "plaintext", the "ciphertext" value after Encryption Through jasypt is different, so it is suspected that the "key" should be in the ciphertext itself, in addition, the encryption algorithm used should be "reversible encryption algorithm ".

In fact, role access control (RBAC) introduces the concept of role, in order to isolate the user (I .e. the action subject, subject) and privilege (permission, indicating an operation on the resource, operation + resource ).

As a proxy layer between a user and privilege, role decouples the relationship between permissions and users. All permissions should be granted to role rather than user or group. Privilege is a permission granule consisting of operation and resource, indicating an operation of resource. For example, delete news. Role-privilege is the relationship between role-to-role, which is the core of permissions.

For Kasai, the relationship between objective-to-objective is completed by three tables (kasai_users, kasai_roles, and kasai_objects. To construct the relation between objective-to-objective, Kasai adds a relational table kasai_objects_users_roles. At the same time, all resources are managed by role, which forms a permission relationship between users, roles, and resources.

Role-Based Access Control (RBAC) has two major features:

1. The changes between roles and permissions are much slower than those between roles and users. This reduces the complexity of authorization management and management overhead.
2. flexible support for enterprise security policies and great scalability for enterprise changes.

RBAC regards permission authorization as a problem of who, what, and how. In the RBAC model, who, what, and how constitute three tuples of access permissions, that is, "who performs how operations on what (which ".

WHO: The owner or subject of the permission (for example, Principal, user, group, role, actor, etc)
What: the target object or resource (resource, class ).
How: specific permissions (privilege, positive authorization and negative authorization ).
Operator: operation. Indicates how to operate on what. That is, privilege + Resource
Role: a set of roles with a certain number of permissions. The unit and carrier of permission allocation, which aims to isolate the logical relationship between user and privilege.
GROUP: user group, the unit and carrier of permission allocation. Permissions are assigned to the Group Regardless of specific users. A group can contain groups (to inherit permissions) or users. users in a group can inherit the permissions of a group. The relationship between user and group is many-to-many. Groups can be hierarchical to meet the requirements of permission control at different levels.

RBAC focuses on the relationship between role and user and permission. The relationship is called the user assignment (UA) and permission assignment (Pa). The relationship between the left and right sides is the same-to-minus relationship. That is, the user can have multiple role, and the role can contain multiple users.

All RDBMS users know that the N: M relationship requires an intermediate table to store the relationship between the two tables. The UA and PA are equivalent to the intermediate table. In fact, the whole RBAC is based on the relational model.

In fact, the Kasai development team developed a variety of authentication mechanisms (AS/400 server-based authentication, relational database-based authentication, UNIX-based authentication, and Win32-based authentication) during the development process. ), however, from the perspective of product release, in addition to the thorough implementation of the relational database-based authentication method, the other methods are still completely invisible. But it doesn't matter. For common applications, it is enough to provide support for relational database authentication.

In RBAC systems, a user is actually playing a role and can replace the user with an actor. This idea comes from the actor-role mode in business modeling with UML. Given that multiple people can have the same permissions, RBAC introduces the concept of group. Group is also considered as an actor. The concept of user is like a person.

The group and gbac (group-based Access Control) are different. Gbac is mostly used in the operating system. The Group is directly associated with the permission. In fact, RBAC also draws on some gbac concepts.

Both group and user are related to the organizational unit, but not the organizational unit. The two are conceptually different. An organizational unit is an abstract model of a physical company structure, including departments, persons, and positions. The permission model describes abstract concepts. Generally, the organizational structure is modeled using the Party or responsibility mode of Martin Fowler.

The relationship between person and user in party mode is that each person can correspond to a user, but not all users have corresponding persons. The department or organization in the Party can correspond to the group. Otherwise, the group does not necessarily correspond to an actual organization. For example, you can have a group named "deputy manager". Many people share the same responsibilities.

The introduction of the group concept is not only used to solve the problem of the same roles of multiple people, but also used to solve another authorization problem of the Organization: for example, I hope everyone in department a can read the news from department. With such a group corresponding to Department A, you can directly authorize this group.

As a proxy layer between a user and privilege, role decouples the relationship between permissions and users. All permissions should be granted to role rather than user or group. Privilege is a permission granule consisting of operation and resource, indicating an operation of resource. For example, delete news. Role-privilege is the relationship between role-to-role, which is the core of permissions.

Therefore, from this perspective, for the use of the Kasai system, we must first clarify the permission relationships between departments, roles, and users in the existing system, at the same time, the concept of Role user in the current application system is distinguished from the role, permission, and user concepts in RBAC. For existing systems, if you need to use RBAC, We can temporarily put aside the conceptual entanglement. For Web applications, the first step is to make an in-depth analysis of the "permission management granularity" to be used in the application system. Second, grasp the "permission granularity" to control system resources (such as links, buttons, and images... And other resources. If the system does not guarantee that the resources will still be shared in the future, you can assign a role to a specific role. For most public resources, you do not need to consider permission restrictions. Finally, resources are classified based on the daily permissions of roles and users in the existing application system, and corresponding resources are included in the corresponding roles.

References:

Http://sourceforge.net/projects/soap-rbac

Http://sourceforge.net/projects/rolemanager
Http://tech.ddvip.com/2008-01/120138480041599.html
Http://www.phpchina.com/html/73/5173_itemid_10049.html

Http://java.ccidnet.com/art/3539/20080123/1350845_1.html

A group has the root permission "/Kasai/" and the root permission. In terms of permission allocation, group, role, and user all have their own root nodes: "/Kasai/group/", "/Kasai/role/", and "/Kasai/user/". The newly added group, role, or user will be expanded under this node. Because the user's permissions are extended under the "/Kasai/user/" node, it is doomed that users created under normal circumstances cannot obtain operation permissions for users (such: create a user. To solve this problem, the Kasai Development Team introduced a Super User concept when developing the Kasai system, expanded the kasai_users table, and added an ID field to represent a Super User, for super users, the system no longer makes tedious permission judgments and allows all operations to be performed directly.

Kasai uses an open source encryption algorithm-jasypt Encryption Algorithm for user passwords. This Java package provides developers with a simple way to add encryption functions for projects, including: Digest password authentication, text and object encryption, integrated with Hibernate and spring Security (acegi) to enhance password management. Jasypt complies with the RSA standard and provides one-way and two-way encryption technology to protect users' passwords more securely and support binary encryption. jasypt can encrypt objects, files, and numbers as needed, apart from text and binaries, jasypt can also be classified and encrypted with numeric values (biginteger, bigdecimal or other types). It supports hibernate persistent encryption and secure threads, provides non-configured encryption tools and flexible configuration, defines domain encryption in the hibernate ing file, seamlessly integrates with spring applications, and spring Security (acegi Security) option integration is suitable for executing password encryption and matching tasks. By using a secure password encryption mechanism and providing higher configuration and control, the security of user passwords is improved, it is more intentionally thought that for the same "plaintext", the "ciphertext" value after Encryption Through jasypt is different, so it is suspected that the "key" should be in the ciphertext itself, in addition, the encryption algorithm used should be "reversible encryption algorithm ".

In fact, role access control (RBAC) introduces the concept of role, in order to isolate the user (I .e. the action subject, subject) and privilege (permission, indicating an operation on the resource, operation + resource ).

As a proxy layer between a user and privilege, role decouples the relationship between permissions and users. All permissions should be granted to role rather than user or group. Privilege is a permission granule consisting of operation and resource, indicating an operation of resource. For example, delete news. Role-privilege is the relationship between role-to-role, which is the core of permissions.

For Kasai, the relationship between objective-to-objective is completed by three tables (kasai_users, kasai_roles, and kasai_objects. To construct the relation between objective-to-objective, Kasai adds a relational table kasai_objects_users_roles. At the same time, all resources are managed by role, which forms a permission relationship between users, roles, and resources.

Role-Based Access Control (RBAC) has two major features:

1. The changes between roles and permissions are much slower than those between roles and users. This reduces the complexity of authorization management and management overhead.
2. flexible support for enterprise security policies and great scalability for enterprise changes.

RBAC regards permission authorization as a problem of who, what, and how. In the RBAC model, who, what, and how constitute three tuples of access permissions, that is, "who performs how operations on what (which ".

WHO: The owner or subject of the permission (for example, Principal, user, group, role, actor, etc)
What: the target object or resource (resource, class ).
How: specific permissions (privilege, positive authorization and negative authorization ).
Operator: operation. Indicates how to operate on what. That is, privilege + Resource
Role: a set of roles with a certain number of permissions. The unit and carrier of permission allocation, which aims to isolate the logical relationship between user and privilege.
GROUP: user group, the unit and carrier of permission allocation. Permissions are assigned to the Group Regardless of specific users. A group can contain groups (to inherit permissions) or users. users in a group can inherit the permissions of a group. The relationship between user and group is many-to-many. Groups can be hierarchical to meet the requirements of permission control at different levels.

RBAC focuses on the relationship between role and user and permission. The relationship is called the user assignment (UA) and permission assignment (Pa). The relationship between the left and right sides is the same-to-minus relationship. That is, the user can have multiple role, and the role can contain multiple users.

All RDBMS users know that the N: M relationship requires an intermediate table to store the relationship between the two tables. The UA and PA are equivalent to the intermediate table. In fact, the whole RBAC is based on the relational model.

In fact, the Kasai development team developed a variety of authentication mechanisms (AS/400 server-based authentication, relational database-based authentication, UNIX-based authentication, and Win32-based authentication) during the development process. ), however, from the perspective of product release, in addition to the thorough implementation of the relational database-based authentication method, the other methods are still completely invisible. But it doesn't matter. For common applications, it is enough to provide support for relational database authentication.

In RBAC systems, a user is actually playing a role and can replace the user with an actor. This idea comes from the actor-role mode in business modeling with UML. Given that multiple people can have the same permissions, RBAC introduces the concept of group. Group is also considered as an actor. The concept of user is like a person.

The group and gbac (group-based Access Control) are different. Gbac is mostly used in the operating system. The Group is directly associated with the permission. In fact, RBAC also draws on some gbac concepts.

Both group and user are related to the organizational unit, but not the organizational unit. The two are conceptually different. An organizational unit is an abstract model of a physical company structure, including departments, persons, and positions. The permission model describes abstract concepts. Generally, the organizational structure is modeled using the Party or responsibility mode of Martin Fowler.

The relationship between person and user in party mode is that each person can correspond to a user, but not all users have corresponding persons. The department or organization in the Party can correspond to the group. Otherwise, the group does not necessarily correspond to an actual organization. For example, you can have a group named "deputy manager". Many people share the same responsibilities.

The introduction of the group concept is not only used to solve the problem of the same roles of multiple people, but also used to solve another authorization problem of the Organization: for example, I hope everyone in department a can read the news from department. With such a group corresponding to Department A, you can directly authorize this group.

As a proxy layer between a user and privilege, role decouples the relationship between permissions and users. All permissions should be granted to role rather than user or group. Privilege is a permission granule consisting of operation and resource, indicating an operation of resource. For example, delete news. Role-privilege is the relationship between role-to-role, which is the core of permissions.

Therefore, from this perspective, for the use of the Kasai system, we must first clarify the permission relationships between departments, roles, and users in the existing system, at the same time, the concept of Role user in the current application system is distinguished from the role, permission, and user concepts in RBAC. For existing systems, if you need to use RBAC, We can temporarily put aside the conceptual entanglement. For Web applications, the first step is to make an in-depth analysis of the "permission management granularity" to be used in the application system. Second, grasp the "permission granularity" to control system resources (such as links, buttons, and images... And other resources. If the system does not guarantee that the resources will still be shared in the future, you can assign a role to a specific role. For most public resources, you do not need to consider permission restrictions. Finally, resources are classified based on the daily permissions of roles and users in the existing application system, and corresponding resources are included in the corresponding roles.

References:

Http://sourceforge.net/projects/soap-rbac

Http://sourceforge.net/projects/rolemanager
Http://tech.ddvip.com/2008-01/120138480041599.html
Http://www.phpchina.com/html/73/5173_itemid_10049.html

Http://java.ccidnet.com/art/3539/20080123/1350845_1.html

Http://java.e800.com.cn/articles/2007/413/1176400843016628730_1.html