Access Control Scenario Two

Scenario Description

User X can use Artifact Y only for records determined by Constraint Z.

Current Implementation Example

A user can create/update/delete their own contact mechanism, even when they don't have any other Party component permissions.

In the Party component, code is inserted in various artifacts to check for contact mechanism security:

1. 11 services have permission checks

   <service name="createPartyPostalAddress" engine="simple" ...>
     <description>Create a Postal Address</description>
     <permission-service service-name="partyContactMechPermissionCheck" main-action="CREATE"/>
     ...
   </service>
   

2. Screen widgets have conditional elements checking for security

   <screen name="CommonPartyDecorator">
     <section>
       ...
       <widgets>
         <decorator-screen name="main-decorator" location="${parameters.mainDecoratorLocation}">
           <decorator-section name="pre-body">
             <section>
               <condition>
                 <and>
                   <if-has-permission permission="PARTYMGR" action="_VIEW"/>
                   <not><if-empty field="party"/></not>
                 </and>
               </condition>
               ...
             </section>
           </decorator-section>
           <decorator-section name="body">
             <section>
               <!-- do check for PARTYMGR, _VIEW permission -->
               <condition>
                 <if-has-permission permission="PARTYMGR" action="_VIEW"/>
               </condition>
               <widgets>
               ...
   

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

<simple-method method-name="partyContactMechPermissionCheck" short-description="Party contact mech permission logic">
  <if-empty field="parameters.partyId">
    <set field="parameters.partyId" from-field="userLogin.partyId"/>
  </if-empty>
  <if-compare-field to-field="userLogin.partyId" field="parameters.partyId" operator="equals">
    <set field="hasPermission" type="Boolean" value="true"/>
    <field-to-result field="hasPermission"/>
    <else>
      <set field="altPermission" value="PARTYMGR_PCM"/>
      <call-simple-method method-name="basePermissionCheck"/>
    </else>
  </if-compare-field>
</simple-method>

The user must have the PARTYMGR_VIEW permission to view his/her contact mechanisms.

New Design Implementation Example

There is no permission checking code in the contact mechanism service definitions or in the screen widgets. The existing partyIdPermissionCheck service is used to check if the user equals the contact mechanism party (it would be helpful to rename the service userEqualsParty or userIsParty).

The user is assigned the following permissions:

Using the static artifact hierarchy

OFBiz/party/service/createPartyPostalAddress[access=true, service=partyIdPermissionCheck]
OFBiz/party/service/updatePartyPostalAddress[access=true, service=partyIdPermissionCheck]
(nine more contact mechanism service artifacts with the same permission list)
OFBiz/party/screen/viewProfile[view=true]
OFBiz/party/screen/editcontactmech[view=true, create=true, update=true, service=partyIdPermissionCheck]

Using the dynamic artifact hierarchy

OFBiz/party/party/partymgr/createPartyPostalAddress[access=true, service=partyIdPermissionCheck]
OFBiz/party/party/partymgr/updatePartyPostalAddress[access=true, service=partyIdPermissionCheck]
(nine more contact mechanism controller request artifacts with the same permission list)
OFBiz/party/party/partymgr/viewProfile[view=true]
OFBiz/party/party/partymgr/editcontactmech[view=true, create=true, update=true, service=partyIdPermissionCheck]