After reviewing the Asset Maintenance component's method of overriding
security, I understand the concern from Adrian in the other thread.
This is something I left off the email below so I thought I would
amend it now.
While this is a really creative workaround for the limitations in the
current security implementation, it is by no means an ideal solution.
It is even more logic spread out in even more places making
understanding and customizing authorization even more cumbersome.
For these exact situations, the auto-grant functionality was
implemented. So, instead of using ECAs to override permissions, you
would define seed data (in the Asset Maint component, SFA, etc) which
define which permissions are granted when a user is granted a specific
application permission.
There is a Use Case defined in the document (http://docs.ofbiz.org/x/-
B0) which explains how this would work for the SFA application.
Just for the record, nothing will break. The two frameworks can live
side by side during the migration process. It is my plan to knock this
out as quickly as possible, one application at a time. Also, I believe
HWM is going to help by providing some resources to assist in the
effort.
Andrew
On May 1, 2009, at 1:36 PM, Andrew Zeneski wrote:
I'd like to move the discussion of the new Authz security
implementation to this thread. To start off the discussion I will
briefly describe what I would like to propose as the NEW best
practices.
1. Single point of contact for ALL security checks, instead of
having security embedded in functionality, or tied to services
directly, the API should be the governor of all security. This means
no more writing security logic in the functionality, and no more
permission services attached directly to functionality (services or
ecas). This is a bad design IMHO because it spreads the permission
logic around in multiple places and makes it impossible to get the
same results when checking permissions from different framework tools.
-- We want to be consistent, and be able to obtain the same
information from the UI or screen/form as we would get from a
service call.
-- Main point of contact is the Authorization interface.
2. Permission services become Dynamic Access (DA). Now instead of
having permission services attached to services, we have Dynamic
Access implementations which can be a compiled Java object, a Groovy
script or a Service. My personal preference here is the Groovy
script, but the API current supports all three. This DA logic is
attached to a permission instead of a service.
-- This allows for extending or changing the permission logic for a
specific implementation/customization/application much easier. Since
the DAs are all data driven, changing the seed data you can change
the logic which is used. This means you no longer have to customize
the services or logic in OFBiz to change the way authorization is
handled for your company (or client); one less thing to worry about
when merging customizations with the open source project.
-- for groovy use "component://path/to/script.groovy" in the
dynamicAccess field on SecurityPermission.
-- for services use "service:serviceName" in the dynamicAccess field
on SecurityPermission
-- for objects use "org.ofbiz.path.to.Object (which implements
DynamicAccess)" in the dynamicAccess field on SecurityPermission
3. Avoid having to check multiple permissions, for example
PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission
format which embeds all permissions which will be accepted:
Example: update:party:contact:10000 - Update the contact information
for party 10000
This will allow anyone who has:
"update" or "update:party" or "update:party:contact" or is granted
record level access by the DA logic.
4. Define permission for users, not admins. Instead of looking for a
static permission, set the permission to be checked at the most
granular level. When doing so, admin users will always have
permission and the API will handle user access using DA logic.
-- see: http://docs.ofbiz.org/x/JR4
That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a
lot more details; interested parties are encouraged to read it
through.
Andrew
