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
