I'm sure it is no surprise that I like the #4 design the best - I
think
it matches the design I proposed.
What IS surprising is the lack of response. We had a lively discussion
on the subject of security design a week ago, and now there doesn't
seem
to be much interest in it.
-Adrian
David E Jones wrote:
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
