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:
- 11 services have permission checks
Code Block xml xml <service name="createPartyPostalAddress" engine="simple" ...> <description>Create a Postal Address</description> <permission-service service-name="partyContactMechPermissionCheck" main-action="CREATE"/> ... </service>
- Screen widgets have conditional elements checking for security
Code Block xml xml <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:
Code Block | ||||
---|---|---|---|---|
| ||||
<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
Info |
---|
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 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]