I haven't seen any additions to this original list in the attempt to
brainstorm, so I guess we're ready to start discussing the merits of
each of these approaches.
Please comment!
To get this started I'll express my opinions on the topic. In short,
#4 is cool and 1-3 are crap. Is that biased enough for you? Well,
here's why I say that. Right now in order to configure permissions and
introduce more granular permissions as needed you have to edit some
sort of XML files (or in some case Java files or other things)
possibly including screen defs, service defs, and service
implementations. The most important part of point #4 is that
authorization settings will be totally external to these artifacts. In
other words, the authorization settings will refer to the various
artifacts instead of the artifacts pointing to the authorization
settings.
IMO that's the most important point: if security can't be configured
by an end-user and through run-time evaluated data (preferably in the
database so multiple app servers stay consistent, etc), then what's
the point? The security config in OFBiz would still be a large,
expensive, PITA.
That said, other biased comments are now needed to balance the bias I
just threw into this... ;)
-David
On May 4, 2009, at 11:53 AM, David E Jones wrote:
This thread is specifically for discussing possible configuration
patterns to use in OFBiz going forward. Please keep other discussion
in another thread, including the merits of each possibility... let's
just brainstorm in this thread.
To get things started, here are the patterns that have been
discussed recently (in high level terms, we can get into
implementation and specific practices later on), these are in no
particular order:
1. artifacts responsible for their own security (especially services
and screens), and security permissions are referred to directly (ie
the actual permissions are configured directly in the XML tags for
the artifact)
2. artifacts responsible for their own security, and no direct
references are used and instead an indirect security control is
referred to; this is basically the permission service model we've
been using where a permission service is basically a security policy
that refers to permissions, can query/filter/whatever to do record
level security, and in customization the permission service can be
overridden or its function changed by ECA rules without touching any
OOTB code or configuration
3. a hybrid of #1 and #2 where artifacts refer directly to
permissions and there is external configuration based on those
permissions that can add other qualifying permissions and/or invoke
logic to change how that permission is evaluated (ie override the
default behavior of requiring the user to have that permission and
either add additional constraints or allow alternative constraints
even if the user does not have the original permission that
triggered it all); this is recursive so that if an alternative
permission is configured that permission may also have further
alternative permissions; also being recursive if attached logic
evaluates other permissions that may have alternative permissions
and/or permission logic attached to them; as I understand what
Andrew has implemented, this is the pattern he followed
4. artifacts are not responsible for their own security except to
specify whether any sort of permission is required or not (ie a
require-permission attribute, would be true by default; for example
most ecommerce screens would have this set to false); access control
would be configured externally so that you can configure access at
the most granular level possible (we would go ALL the way here,
including: screens, services, forms, form fields, menu items, tree
nodes, etc, etc); the access control tools would have patterns and
features to facilitate grouping of artifacts, grouping of users (ie
just use the current SecurityGroup entity), and support for both
functionality access and record-level access
Can anyone thing of other patterns? Again, PLEASE do not comment on
which one you like better or what you think the advantages or
disadvantages are of each in this thread (of course, definitely
think about such things and feel free to comment in other threads, I
just want this to be a "hat's off" (yes, that is a reference to Six
Thinking Hats by Edward de Bono; anyone who hasn't read that should
give it a go!) brainstorming session.
Thank You!
-David
