I see this new security framework as big step forward. The existing
security system is way too static, I mean permission rules are
embedded in services such that users always need ofbiz DSL (mini lang)
experts to do simple stuff (good job security, If there were customers).
New system opens up doors for building tools that will make Ofbiz
Administrators life lot easy. Like now I can write tools that will
scan all the services/ forms/screen/menu widgets (may request entries
in controller) and present me a tree of
1) Artifacts like services, screens, forms. Resources that you will
like to secure.
2) List of different levels of permissions.
Artifact node will show permission needed and children nodes that are
list of users who have access the them.
Permission node can list users who have those permission and list of
artifacts that are allowed to use at that level.
Administrator will be able to add or remove user or change level of
access.
If done right permissions in special purpose applications will be much
more manageable. Auto-grant functionality can be {quote} extended
{quote}, we can connect it with date model that stores permission
dependency.
e.g When user is granted "update:sfa:contact:10000" permission, How
will security framework know that its same as "update:party:10000"? We
can setup data for mapping special purpose permissions with
fundamental permissions. So when security framework finds that called
service requires "update:party:10000" permission and user does not
have it then figure out if user have permissions that are equivalent
or better then "update:party:10000" permission.
Auto-grant concept can be extended for securing higher level
(compound) services that in turn call multiple services. Just an idea,
if we make our request secured like services, then we can secure our
UI components because they know request id.
Also, I believe HWM is going to help by providing some resources to
assist in the effort.
+1
Whatever we decide, I am happy we are thinking about it.
Regards
Anil Patel
On May 1, 2009, at 2:23 PM, Andrew Zeneski wrote:
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.
+1
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
