This is a technical description to explain security in OFBiz.

While implementing the Project manager component, I needed to implement the security too and could not find document describing it.
I am not the designer of this part of the system, I can only describe the results of my investigations going through the source.

The basics of the system are that there are security permissions which consist out of two parts seperated with a '_' character. The first part is the application name and the second part is the action or operation. The application is normally the same as the component name however in uppercase characters. The action can be anything however the most used are : VIEW, CREATE, UPDATE, DELETE and the special one called ADMIN which allows all operations.
An example is the security permission for creating a  order is ORDERMGR_CREATE, in this case the application is the ordermanager and the action is 'CREATE' to create an new order. This permission is contained in the 'ORDERENTRY' security group. So every userId which is connected to this group will be able to create orders.

It appears that we currently have several systems/levels where this is implemented:

1. At login level
   In the file ofbiz-component.xml the base-permission is defined. The user who want to logon needs to have at least the base-permission COMPONENT-NAME_VIEW or basepermission COMPONENT-NAME_ADMIN permissions to be able to logon.  Most of the components have the values OFBTOOLS coupled with generaly COMPONENT-NAME permission and this means that both are required to gain access to the component. Beware: using comma as an and operator is not obvious and has proven to be a source of confusion in the past.
2. At the component menu level
   The component top-level menu will only show the components to which a logged-on user has at least the WEBAPPNAME_VIEW or COMPONENTNAME_ADMIN permissions, i.e. the same as on the login level.
3. At the request (controller.xml) level
   Here there are  2 parameters important. Every request (<request-map) tag has a security (<security) tag with the 2 parameters: 'https' to define if SSL will be used for this request and the 'auth' parameter to define if a user needs to be logged on to execute this request. If he is not logged on the login screen will be shown and after a sucesful login AND if the security checking on the other levels are succesful, the request will be executed.
4. At screen level
   In the '<section' part of a screen definition and '<condition' tag the  test with the  '<if-has-permission' tag with the 'permission' and 'action' test can be performed. Depending on the outcome the  '<widgets>'  or '<fail-widgets>' can be shown.
5. At service definition level (currently being implemented)
   This is a rather new function which allows the re-usage of services in other components with a different security schema. An example is the project manager component which uses many services of the workeffort component but has a different security schema.
   In the service definition, (files in the servicedef directory) the '<permission-service' can be inserted poiting to a service which will check if the service is allowed to be executed. The input to this service is at least the 'main-action' parameter to specify the action (CREATE, UPDATE etc) but also any other input parameter such as a productId, or workEffortId as defined is the security service.
6. At service program level.
   1. Minilanguage.
      Using the <check-permission tag to check the access.
   2. Java.
      Using the org.ofbiz.security.Security API

All these levels rely on several database tables:

1. SecurityPermission: the lowest level where all basic permissions are defined.
2. SecurityGroup: where the permission group is defined
3. SecurityGroupPermission: permissions are grouped together in this table.
4. UserLoginSecurityGroup: Which userLogin id's have access to which permission groups
5. PartyRelationship: security groups can be set for certain party relationships.