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
