I think enough time has passed, but clearly if anyone has any comments
for configuration patterns please speak up!
Now to the point: I propose that we use this list as a set of
requirements to use to evaluate all future proposals for security
improvements, especially related to configuration of authorization.
Does anyone disagree with doing that? (If so we should discuss it more
as needed, and if needed also vote on it)
-David
On May 6, 2009, at 1:46 PM, David E Jones wrote:
There has been a bit of discussion in this thread (and most of it on
topic, so thanks for that), but in reviewing it I can't find any
specific alternatives to add to this list. I'd like to move on to
discussing the merits of these things soon and see which approach we
each like best (or worst!), so if there is anything anyone would
like to add to the list or if anyone has questions about any items
on this list please speak up!
-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
