Page History

...

If each artifact has its own set of permissions, there could be potentially thousands of permissions - an administration nightmare! It would be helpful to have artifact permissions organized in a hierarchy - so that permissions defined higher up in the hierarchy are inherited by artifacts lower in the hierarchy. The hierarchy will reduce the number of permissions needed.

Note
The following hierarchy has been called a "static hierarchy" and it is not finalized. There is an alternative to it called "dynamic hierarchy" - see below.

The components in OFBiz are organized in a hierarchy, and each component typically contains entities, services, and screen widgetsAn execution path could be considered a hierarchy. We can build on that structure to set up a hierarchy of security-aware artifacts:

OFBiz
- Component applications
  - WebApp accounting
    - ControllerRequest entity
      - ControllerRequestEvent Budget
        BudgetAttribute
        Service
        ...
        Entity
        PartyRate
        EntityField
        service
        ControllerView
        WidgetScreen createPartyAcctgPreference
        updatePartyAcctgPreference
        Service
        ...
        Entity
        payflowCCRefund
        EntityField
        screen
        FtlFile
        FindAgreement
        WidgetScreen
        EditAgreement
        ...
        WidgetForm
        WidgetFormField
        ViewGatewayResponse
        ...
        Permissions assigned at the OFBiz/applicationscomponent/accounting webapp level are inherited by all artifacts below that level. Permissions assigned at lower levels replace any inherited permissions. Permission inheritance is managed by the authorization manager.
        In the design overview, it was mentioned that the security-aware artifact provides its identifier to the authorization manager when requesting permissions for itself. That identifier must be unique in order for the system to work. We can leverage the artifact hierarchy to construct a unique artifact identifier. The Budget entity's identifier would be OFBiz/applications/accounting/entity/Budget. The FindAgreement screen's identifier would be OFBiz/applications/accounting/screen/FindAgreement. The authorization manager should handle the identifier in a case-insensitive way.authorization manager should handle the identifier in a case-insensitive way.
        The "OFBizThe "OFBiz" portion of the identifier is considered the root of the hierarchy. The "applications" and "framework" portions of the identifiers could be left out of the design.
        The permission list returned by the authorization manager is a set of flags - implemented as key/value pairs. The flag key indicates the type of permission - view, create, update, delete, etc. Valid flag values are "true" or "false." A value of "true" indicates access-granted, and a value of "false" or the absence of a key/value pair indicates access-denied. The permission list could consist of the standard view, create, update, and delete permissions. Artifacts are allowed to define additional permissions. For example, a web application or service artifact might need only one permission - access.
        ...
        Note that parentAuthorizationState will never be set to "Deny" because before that would happen the auth would have failed and an error sent back up the stack.
        ...
        .
        ...
        Example Chain:
        ...
        ControllerRequestEvent
        Service
        Entity
        EntityField
        ...
        Entity
        EntityField
        ...
        WidgetScreen
        ...
        Authorization Manager Implementation
        ...

Space shortcuts

Child pages

Versions Compared

Old Version 32

New Version 33

Key

Example Chain:

Authorization Manager Implementation