Thanks for your effort on this Adrian.
A few points of feedback (written as I read through this):
1. the hierarchy of artifacts should not be static as you have
described; what we care about for access control is how an artifact is
used, not where it is statically located; for example we don't care if
the AcctgTransEntry entity is part of the accounting component, but we
do care if it is used by service X or in screen Y or in webapp Z; in
other words, the hierarchical description for the context of a
resource isn't static, it is built up at run-time as things are being
executed; this is a big problem with the current security stuff, and
something Andrew started to address but that wasn't fully fleshed out
1-Redux. jumping back to this comment after reading the "Artifact
Reuse" section: this starts to address the issues of artifacts being
used in different places, but I'm not sure if the idea of the
hierarchical string adequately addresses the issues since the chain of
artifacts used will vary in dramatic ways for different operations, ie
for a larger webapp request and response you'd have a huge tree of
artifacts called, and they would be different and in different orders
than artifacts called in other requests; I've been writing up an
entity model and some implementation notes to support features implied
by the model (based on some of these discussions) and I have some
ideas about how we might configure to support this concept, and what
the implementation might look like (isn't actually too complicated,
but there are some important/key points)
2. I don't like the idea of "User Group", "User Role" and "Policy"; it
is confusing to have the multiple terms that mean slightly different
things, and things that overlap in some ways with existing OFBiz
concepts; I also don't think we need 2 levels of grouping between a
user and what it has access to; in other words the current
SecurityGroup that is used instead of referring directly to users is
adequate as it takes care of not having to duplicate access control
configuration for multiple users without adding too much complexity; I
know this came from discussion in an email thread, but this seems to
include every possible idea and try to make them fit together somehow
instead of picking a single concept and making it work; in other words
if someone is used to calling something a "role" or a "group" or a
"policy" it won't make it any simpler if they get into the UI and all
three are present and all three used in slightly different ways from
what they are used to... the goal to make it easy for users of other
systems to use it fails, and the goal to make it work well on its own
also fails; hopefully this is okay, and I think so based on your
comments in a blue info box about just using the User Groups (and
hopefully I've expressed why I agree with that approach here)
3. we should support services to check authorization and also support
configuration of record-level permissions; in most cases these are
really simple with just a view-entity that goes between the
userLoginId or partyId and some other end-point, like a productId or a
partyId, with specific constraints along the way (like a
productCategoryI, productCategoryTypeId, roleTypeId,
partyRelationshipTypeId, etc); for the most part I think we should try
to eliminate the services that do permission checks and instead make
it all configurable; also, if there is a service involved it should be
referenced in the database-driven configuration and NOT in the
artifact itself (again the goal is to get those out of the artifacts
so that they are more readily and flexibly configurable)
Anyway, that said I think this going in just the right direction and I
look forward to comments from others on this too (it would be great to
see discussions about actual aspects of requirements, design, and
implementation to get as much action as discussions of how we
collaborate... ie hopefully we'll do more collaborating than talking
about if and how to collaborate... ;) ).
I have posted my notes at the bottom of the page you created (http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor
). Hopefully those will help clarify what I tried to describe above in
this message, and also lay some groundwork for the technical design.
For that as well comments are welcome (and hoped for!).
-David
On May 13, 2009, at 3:10 PM, Adrian Crum wrote:
Done - http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor.
I was going to spend more time on it to add more detail, but since
we're in such a hurry I posted it as-is.
-Adrian
Adrian Crum wrote:
Cool - thanks. I was going to post it as a PDF, but I can C&P it
into a Wiki page.
-Adrian
David E Jones wrote:
Well, THAT explains it!
A wiki page is probably the best place for things like this
(that's where I found myself looking anyway...). That will allow
collaboration on working the document and getting things setup for
development.
-David
On May 13, 2009, at 2:14 PM, Adrian Crum wrote:
lol - that's what I was asking you. I have the document ready,
where should I put it where everyone can find it? Do we want to
create a Wiki page or Jira issue? I'm sure we will need some
place to collaborate.
-Adrian
David E Jones wrote:
Okay, I give up trying to find it or a link to in my email
history... where is your document Adrian?
-David
On May 13, 2009, at 12:58 PM, Adrian Crum wrote:
I have the design document ready, I just don't know what to do
with it.
-Adrian
David E Jones wrote:
I think the sentiment in the thread is that more feedback
would be really helpful. It's kind of the lack of discussion
that seems to be holding this back.
At this point I don't see any comments that argue against item
#4, so unless someone hops in with comments, issues, or
additional requirements then we'll just go with that.
The next step, aside from the work that Adrian is doing, is to
get the data model going for this external configuration of
authorization that fits for this pattern and the requirements
in the other thread.
-David
On May 13, 2009, at 8:57 AM, Tim Ruppert wrote:
+1 - that's what I was saying - let's get back on this horse
and make these improvements! We all know it's sorely needed
- don't let discussion stop us from making an impact.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
----- "Adrian Crum" <adri...@hlmksw.com> wrote:
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
