THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
When an artifact receives a list of permission services in addition to the list of permission flags, it will process the permission flags first, then the list of permission services.
| Info |
|---|
The existing permission services can be reused in the new design. Many of the existing permission services check a permission flag (mainAction), and then do some additional processing. To convert those permission services over to the new design, just remove the permission flag check. |
A special case exists for entity lists. Sometimes it is desirable to filter a list of records based upon the user. Treating each record as an artifact and performing permission checks on them one at a time would be inefficient. We need a way to specify a filter.
...
Authorization Manager Artifact | Properties |
|---|---|
User | IsUser, HasPermissions, IsMember |
User Group | HasPermissions, IsMember, HasMembers |
User Role | HasPermissions, IsMember, HasMembers |
Policy | HasPermissions, IsMember, HasMembers |
...
, HasMembers | |
User Role | HasPermissions, IsMember, HasMembers |
Policy | HasPermissions, IsMember, HasMembers |
The Authorization Manager must support the following operations:
...
Other operations could be included to support a security administration user interface.
| Info |
|---|
To simplify implementation, the AM could support just users and User Groups. OFBiz administrators could implement User Roles and Policies using the User Groups. |
The AM is a security-aware artifact. Users must have the appropriate permissions to perform any of the AM create/delete operations.
...
A user could be made an admin of all of OFBiz by assigning granting the user admin permission to the OFBiz (root) artifact for that user.
Artifacts must treat the admin permission as expected - it is the same as having all permissions. If the admin permission appears in a list of permission flags, it takes precedence - all other permission flags and permission services are ignored.
...