Preliminary authority design of OFBiz

Brief introduction

Apache Open for Business (Apache OFBiz) is a classic ERP project for Apache Open source. It provides a set of enterprise applications for integrating and automating some enterprise "business processes".

From a learning point of view, it is also a very good enterprise-class application framework. This article from OFBiz's authority design this point of entry to talk about the OFBiz to the application system's permission design.

Brief Introduction to design ideas

OFBiz uses the security group to associate permissions with the user. "" There are several kinds of permissions in the system, such as the permissions of the system presets, the user-defined permissions, the permissions of the resources, the permissions of the operation, and so on, which will establish a relationship with the security group (many-to-many relationships), and the user and the security group (also many-to-many relationships).

Where the system preset permissions are imported into the data table in the form of an XML configuration. These configuration files typically have a path of {component/application basedir}/data/xxxsecuritydata.xml. Here is the initialization data for the entire permission design-related table.

Permission Control Level

OFBiz has the following levels of control for permissions:

Logon level

Under the Ofbiz-component.xml file in the root directory of each component, there is a " most basic permission " definition for accessing the component. The so-called basic privilege is that the user who logs on to the component needs to have at least the permissions defined in the file to be accessible. Example:

See the "base-permission" attribute. You can see that it contains two permission value--ofbtools/facility, which means that you must have both permissions to access the component. In general, a component also contains the permissions "Ofbtools" as well as the rights "Componnent-name_view", so that the purpose of the configuration is ofbtools to control access to the Web app, and Componnent-name_ View controls the information for browsing the Web App.

Component Menu Level

COMPONENT's top-level menu displays components that appear only to logged-in users (and those users have at least "Webapp-name_view" or "component_name-admin" permissions), similar to the logon-level restrictions. This level of access control is implemented in "APPBAR.FTL" to control which applications are displayed in the tab bar.

Request (Controller.xml) level

There are two important parameters here, each request (<REQUEST-MAP) tag in Controller.xml under each component WebApp has a security (<security) tag, Contains two properties:

• HTTPS: Defines whether SSL encryption is applied to the request
• Auth: Defines whether a login is required to execute the request, so the request will not be executed until the login is successful and security checks at other levels have passed

[JavaScript]View PlainCopy

1. <!--Request Mappings-
2. <request-map uri="Marketingreport">
3. <security https="true" auth="true"/>
4. <response name="Success" type="View" value="Marketingreport" />
5. </request-map>

Screen level in the screen configuration file under the Widget folder under each component, the <condition child node under the <section node, there is a node named <if-has-permission. It has two properties:

• Permission: Identifies which component is located
• Action: Identifies the action performed

The permission_action exactly constitutes a permission, example:

Freemarker template Fragment level Session variable: Security is always present in the context object--context of screen, and you can use a defined Java method in the template: haspermission; hasentitypermission; hasrolepermissionService definition level You can define specialized "Permission service" to be reused in different security modes, different component, where you can insert permission validation by extending the rules of ECA. Details beyond this article can be referenced in the example 'examplegenericpermission '(under example component) service programming level there are two ways of doing this:

• Minilanguage: Using the <check-permission tag, note: Minilanguage is a unique XML-based "language" of ofbiz.
• Java: Using Org.ofbiz.security.Security.API

Record level for example, for a specific constraint entity, a query based on it, you must have specific permissions to obtain the corresponding result role limited (or role-based) permissions (also known as party Roles) the same as the record level, by using Roletype, Partyrole and related entities, such as Contentandrole, for control. Note: The roles here tend to business rules and are completely different from the "Role" security role security roles discussed below provide a means to associate a login user with a special ofbiz "element", for example, if a user is assigned Ordermgr_view permissions, The user is also associated with a particular group (assumed to be XYZ company, which has a ordermgr_role_update security role). Then such a combination will allow the user to browse all rights that belong to the company, and can update orders only for that company. Data Sheet Structure Design

First, let's take a look at the table structure design of the ofbiz for permissions, which involves 6 data tables altogether:

• Security_group
• Security_permission
• Security_group_permission
• User_login_security_group
• Party_relationship
  
• Security_permission_auto_grant (no discussion)

Security_group

This is the data table for the "security group" mentioned above, and the user indirectly has a relationship with the permission by belonging to a security group. A security group can be simply considered to be a collection containing n permissions.

Security_permission

Permissions table, which defines all the permissions in the system. One of the most important things to focus on is the first two fields:

1. PERMISSION_ID: A permission name: usually defined in the form of "Application_operate" (where application represents the specific name of the application, Operate represents the action name, and is commonly used create/update/ ... ）。 Of course, there are some special naming methods, such as: "Marketing_view" for the MARKETING application of the page has view rights; "Manual_payment" represents the transaction operation rights of manual payment; "Marketing_admin" Here admin as suffix is a special, indicating that it has all the operation permissions on the marketing application.
2. DESCRIPTION: A brief description of permission_id

Security_group_permission

As described above in the design idea, this is the "Group" and "Permission" of the many-to-many relationship table. Semantically it is not difficult to understand that a security group can have multiple permissions, and a permission can also be subordinate to multiple security groups.

User_login_security_group

It is also easy to see the name of the user security group, which is also a many-to-many relational table (note the primary key definition). As we can see, this table does not just combine the primary key of the two tables as the Federated primary key, but instead unites the "From_date" and the three unions as the primary key. Here we need to focus on a design pattern commonly used in the OFBiz data sheet- expire rather than delete。 In other words, many relationships are timeliness, and these timeliness is reflected in the "From_date" and "Thru_date" two fields. If the current record is found to be out of date, then it is considered invalid, which is equivalent to our traditional "delete record" operation. This design approach avoids the various exceptions and data consistency constraints that can be caused by foreign key problems when deleted in a complex enterprise application. Party_relationship

You can see that the table contains a SECURITY_GROUP_ID field that is used to associate a security group (which is usually null). Because the security group was only associated with the user, and the user is a party, the party can contain any individual, user, organization and so on. Party_relationship can be used to describe the relationship between any two things, which are sometimes not just people, so they may sometimes need to have permissions, not just the logged-on user. Key code Interpretation

After reading the datasheet design, let's look at the code implementation, the permission-related code is encapsulated as "security" component, located under the {Base_dir}/framework/security/src folder, The main operations are abstracted in an interface called security, where the interface consists of several key methods:

[Java]View PlainCopy

2. Public    iterator<genericvalue> Finduserloginsecuritygroupbyuserloginid (String Userloginid);
6. Public     boolean securitygrouppermissionexists (String groupId, string permission);
10. Public     boolean haspermission (String permission, HttpSession session);
14. Public     boolean hasentitypermission (string entity, string action, HttpSession session);
18. Public  boolean hasrolepermission (String application, String action, String PrimaryKey, String role,    HttpSession session);
22. Public     void clearuserdata (Genericvalue userlogin);

which

The first method is to query the user's permission group according to the user ID;

The second method is to check whether a security group has a permission

A third method is to determine whether a user has a permission (the information about the user is encapsulated in the session)

The fourth method determines whether a user has permission to operate an entity

The fifth method determines whether a role has permission

The sixth method is clear of all cached data related to the user (this method is called by the framework when the user exits the login)

Note: The above three hasxxx methods have different overloads

Then look at the key code in the default implementation (Ofbizsecurity.java) in ofbiz:

[Java]View PlainCopy

2. Public boolean hasentitypermission (string entity, String action, Genericvalue userlogin) {
4. if (Userlogin = = null) return     false;
8. //if (Debug.infoon ()) Debug.loginfo ("hasentitypermission:entity=" + entity + ", action=" + action, module);   
10. iterator<genericvalue> Iterator = Finduserloginsecuritygroupbyuserloginid (userlogin.getstring ("    Userloginid "));
12. Genericvalue Userloginsecuritygroup = null;
16. while (Iterator.hasnext ()) {
18. Userloginsecuritygroup = Iterator.next ();
22. //if (Debug.infoon ()) Debug.loginfo ("hasentitypermission:userloginsecuritygroup=" +  Userloginsecuritygroup.tostring (), module);   
26. //Always try _admin first so it'll cache first, keeping the cache smaller   
28. if (Securitygrouppermissionexists (userloginsecuritygroup.getstring ("groupId"), entity + "_admin" ))    
30. return     true;
32. if (Securitygrouppermissionexists (userloginsecuritygroup.getstring ("groupId"), Entity + action ))    
34. return     true;
36. }
40. return     false;
42. }

This is the final implementation of the hasentitypermission, we can see that it will first try to append the "ADMIN" string in the entity, that is, to see the super permission, if you have super permissions, it is directly considered to have permissions, otherwise will be to see fine-grained specific permissions.

[Java]View PlainCopy

2. Public boolean hasrolepermission (String application, String action, string PrimaryKey, list<string > Roles, Genericvalue userlogin) {
4. String entityname = null;
6. Entitycondition condition = null;
10. if (Userlogin = = null)
12. return     false;
16. //Quick test for special cases where were just want to check the permission (Find screens)   
18. if (primarykey.equals ("") && roles = = null) {
20. if (Hasentitypermission (Application, Action, userlogin)) return     true;
22. if (hasentitypermission (application + "_role", Action, userlogin)) return     true;
24. }
28. map<string, string> simplerolemap = OFBizSecurity.simpleRoleEntity.get (application);
30. if (Simplerolemap! = null && Roles! = null) {
32. EntityName = Simplerolemap.get ("name");
34. String Pkey = Simplerolemap.get ("Pkey");
36. if (Pkey! = null) {
38. list<entityexpr> expressions = new arraylist<entityexpr> ();
40. for (String role:roles) {
42. Expressions.add (Entitycondition.makecondition ("Roletypeid", Entityoperator.equals, role));
44. }
46. entityconditionlist<entityexpr> exprlist = entitycondition.makecondition (expressions, entityoperator.or);
48. entityexpr keyexpr = entitycondition.makecondition (Pkey, PrimaryKey);
50. entityexpr partyexpr = entitycondition.makecondition ("PartyId", userlogin.getstring ("partyId    "));
52. Condition = Entitycondition.makecondition (exprlist, keyexpr, partyexpr);
54. }
58. }
62. return    hasrolepermission (Application, action, entityname, condition, userlogin);
64. }

The above code can see that in the method will first try to call Hasentitypermission, if there is no permission, try to append the "_role" string after application to see if the role permissions are owned, and if so, return directly, Otherwise, the lookup will continue based on the related Entity-namerole table.

Security_group VS RBAC

I have been involved in a project that has been exposed to the common RBAC (role based access control) permission design idea. Also reprinted an article of the Authority design of OA. in the ofbiz, the concept of the role is weakened, and the concept of "security group" is strengthened. I think it's because of the differences in the size of the system that makes the design difference. RBAC is common in a single system design, in a single system, the role of the word positioning is accurate and clear, and in OFBiz, its goal is to build a set of ERP platform (including multiple heterogeneous systems). Talking about roles across multiple systems has become blurred and confusing, but the concept of a security group does not, and the concept of security groups makes the vectors of the authority more granular and more flexible, but at the same time more complex, so in fact OFBiz still has the role of this concept (embodied in the rights to include _role permissions , which can be considered role permissions). The concept of this "security group" is often used in commonly used RBAC (a special user who needs to be assigned permissions that span multiple roles when the user's permissions need to be customized, which is the concept of a similar security group).

So I think they fit into different scenarios, but they can be combined with each other.

This article briefly introduces the design of authority in OFBiz, first expounds the design idea of ofbiz, then summarizes the level of authority in OFBiz, then analyzes the data table design and key code analysis, and finally compares the security group design mode and RBAC's permission model.

Reference links
http://blog.csdn.net/Liucheng417/article/details/49680185

Preliminary authority design of OFBiz