Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

Access Control Scenario One

Scenario Description

User X can use Artifact Y for anything that artifact supports and on any data (where "artifact" is a screen, web page, part of a screen or page, service, general logic, etc).

Current Implementation Example

In the Example component, code is inserted in various artifacts to check for security:

  1. 13 services have permission checks
    <service name="createExample" default-entity-name="Example" ...>
      <description>Create a Example</description>
      <permission-service service-name="exampleGenericPermission" main-action="CREATE"/>
      ...
    </service>
    
  2. Screen widgets have conditional elements checking for security
    <widgets>
      <decorator-screen name="main-decorator">
        <decorator-section name="pre-body">
          <section>
            <condition>
              <and>
                <if-has-permission permission="EXAMPLE" action="_VIEW"/>
                <not><if-empty field="example"/></not>
              </and>
            </condition>
            ...
        </decorator-section>
        <decorator-section name="body">
          <section>
            <!-- do check for EXAMPLE, _VIEW permission -->
            <condition>
              <if-has-permission permission="EXAMPLE" action="_VIEW"/>
            </condition>
            <widgets>
              ...
    

There is a permission checking service that calls a permission checking script:

<simple-method method-name="exampleGenericPermission" short-description="Main permission logic">
  <set field="mainAction" from-field="parameters.mainAction"/>
  <if-empty field="mainAction">
    <add-error><fail-message message="In the permission-service element for the exampleGenericPermission service the main-action attribute was missing but is required"/></add-error>
    <check-errors/>
  </if-empty>
  <if-has-permission permission="EXAMPLE" action="_${parameters.mainAction}">
    <set field="hasPermission" type="Boolean" value="true"/>
    <field-to-result field="hasPermission"/>
    <else>
      <property-to-field resource="ExampleUiLabels" property="ExamplePermissionError" field="failMessage"/>
      <set field="hasPermission" type="Boolean" value="false"/>
      <field-to-result field="hasPermission"/>
      <field-to-result field="failMessage"/>
    </else>
  </if-has-permission>
</simple-method>

To give a user permission to use these artifacts on any data, the user is assigned four permissions, or the single admin permission.

New Design Implementation Example

This description includes permission expressions that are in the form of ArtifactIdentifier[PermissionsList]. The expressions are illustrative - they are not intended to be some kind of "permission string." How permissions are stored and managed depends upon the Authorization Manager implementation.

There is no permission checking script or service. There is no permission checking code in service definitions or in the screen widgets.

The user is assigned these permissions: OFBiz/Example[access=true, create=true, update=true, delete=true] or the admin permission: OFBiz/Example[admin=true].

  • No labels