Open Source Strategies
 
Main
About
Learn More
Services
Projects
Jobs
Contact

SourceForge.net Logo

Securing your OFBiz Applications

by Si Chen

These are some general notes about how security in OFBiz applications works.

OFBiz can be secured at the user interface or business logic levels. At the user interface level, an entire web application can be secured at once, individual requests in the controller can be secured, and individual pages can require specific permissions. At the business logic level, each service can require a specific permission.

Assigning Permissions

There is a SecurityPermission entity which describes granular security permissions, which could be for a particular page or a particular service. SecurityPermission is a two part string, separated by an "_". The first part specifies the application, the second part the operation allowed. Thus, you could have a permission like "ORDERMGR_CREATE" which means that the user with this permission can create information in the order manager. Some permissions end in _ADMIN, such as ORDERMGR_ADMIN. Those permissions automatically have the right to every operation in the application.

Individual security permissions are grouped together into groups with the SecurityPermissionGroup entity which groups these permissions together. For example, you can create a specific sest of permissions for customer service representatives who can view customer information, enter orders, but not make purchase orders or access internal manufacturing, accounting, or payroll information and functions.

Each SecurityPermissionGroup is associated with a UserLogin. A Party, which can be a Person or a PartyGroup (ie, organization) can be associated with multiple UserLogins. Thus, a Person can have some logins with more permission and some with less, which can be helpful with larger customers (or larger families, for that matter.)

This can all be done in the Party Manager - Security tab.

Securing Web Applications

In the ofbiz-component.xml file where web applications are defined (with the <webapp> directive), you can use the <base-tag> tag to specific required permission for the whole web application. Just use the first part of the security permission string, which is the name of the application. For example, if you put base-permission="ORDERMGR", the webapp will automatically require ORDERMGR_VIEW or ORDERMGR_ADMIN.

In many applications, you will see base-permission="OFBTOOLS, ORDERMGR". What this means is that OFBTOOLS_VIEW and ORDERMGR_VIEW are both required. The base-permission attribute allows a series of permissions to be specified, and all of them must be true at the same time for the user to gain access. The idea behind requiring both OFBTOOLS_ and ORDERMGR_VIEW is so that a OFBTOOLS_VIEW controls the access to the web apps, while ORDERMGR_VIEW can be used to control access to order information in any application, including the web-based Order Manager but also the Point Of Sales store, the CRM module, or another application.

In the controller.xml file for the web application, you can specify security requirements for individual requests with the <security> tag. You can use it for making the page secure with https or requiring a user login (though not a user login with a particular permission) to view the page. You can also hide the request altogether by making unavailable to direct requests from the browser. This might be nice when you have a request which is part of a request chain that should not be called individually.

Finally, on the pages themselves, you can use request that the page does not display unless the user login had certain security permissions. OFBiz supples you with the UserLogin and a "security" object (see Security API below) for checking these permissions in a .bsh file. If you are using screen-widget, you can also use the following tags:

<condition>
  <if-has-permission>
  <check-permission>
<widgets>
<fail-widgets>
They allow you to check permission inside the widget directly without using FTL and then set up a widget for when the permission is checked and a fail-widget when permission is denied.

Security API

The most popular security API methods are:

  • Security.hasPermission - checks if the user has a particular permission
  • Security.hasEntityPermission - will allow you to specify permission strings as two parts, such as "ORDERMGR", "_CREATE", so if the user has "ORDERMGR_CREATE" or "ORDERMGR_ADMIN" permission, it will pass.
  • ServiceUtil.getPartyIdCheckSecurity - will check if the user has the specified permission or is in fact performing the operation for himself (ie, userLogin.partyId == partyId). In either case, will return the partyId, which means the user has permission.
  • Security.hasRolePermission - will check if the user has the specified permission AND if the user is associated with a particular entity in a role. The idea is if you give the user a permission like ORDER_ROLE_VIEW and then specify that he is related to an order with the OrderRole entity, then that user has permission to view that particular order. The same user would not have permission to view orders for which he does not have an OrderRole entity record.

The minilang simple methods also have permission checking tags <if-has-permission> and <check-permission>.

You should also take a look at the full OFBIZ Security API for more information.

Securing Services

You can define whether a service requires a user login. In addition, you can use the <security> tag to define what permissions are required. Inside the services itself, you can get OFBiz to check on permissions for you. There is a security-related method which will check if the UserLogin has certain permissions, or if the user is performing a task for himself (ie, creating an order for himself.)

You can also define your permissions in the services.xml itself by using the <required-permissions> and <check-permission> tags. See applications/product/servicedef/services.xml, for example.

If you would like to work on a tutorial extending the "Hello World" applications to include some security examples, please write on the mailing lists, and I will be happy to direct you on how to do it.


© 2005-2007 Open Source Strategies, Inc. All rights reserved.