Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Security, as discussed in this article, is about permissions being granted to access OFBiz artifacts such as services, screens and data.


Table of Contents

How permissions are organised (the 2 levels of security)


If you need to know more details look at Security Administration 

titleWrong use of "role limited" permissions

Note that a "role limited" permissions to work requires an enforcing relationship to be used. There are currently a number of cases in OFBiz where "role limited" permissions are used without enforcing relationships. For instance often the <alt-permission tag is used in simple methods as if the "role limited" permission would complement the primary user permission when it's actually only redundant since the <check-permission tag is not supposed to infer by itself what to do with this alternative permission. This is explained and discussed in this dev ML thread. In this other user ML thread a solution is proposed to prevent this to spread all over the code. Two other propositions has been discussed some years ago, notably this OFBiz Security Redesign.

There was also this discussion about NIST and RBAC (Role Based Access Control) started by Ruth. But has Adrian's remarked (many times) we have always this technical discrepancy between users (userLogin) and parties (Party). In OFBiz an user and a party have different meanings (a party may use several different userLogins).


For example, the security permission for creating an order, is ORDERMGR_CREATE. The application is the Order Manager (ORDERMGR) and the action is 'CREATE' which indicates that this permission controls the creation of an new order. OOTB, this permission is granted to the 'ORDERENTRY' SecurityGroup entity, so every user ID (userLoginId) which is part of the ORDERENTRY group can create orders. 

We currently have several systems/levels where this is implemented:


At service implementation level.

  • Minilanguage.
    Using the <check check-permission and if-has-permission tag tags to check the access.
  • Java and Groovy.
    Using the API methods such as hasEntityPermission.

At record level, by using Role limited permissions or related means