From: David E Jones <david.jo...@hotwaxmedia.com>
Subject: Re: Brainstorming: Security Requirements/Scenarios
To: dev@ofbiz.apache.org
Date: Saturday, May 16, 2009, 4:14 PM
Sorry for not getting back to this sooner. I spent a little
too much time on it earlier this week and then got a bit
slammed with other things...
I'm glad we're discussing this and not doing any of it
yet... there are some possibly big issues.
The main one that concerns me is this question: what do
permissions on entities mean? If you don't have the
permission, are allowed to do anything with the entity? If
you are not logged in, what is allowed and what isn't? Do we
allow code to circumvent the entity security by explicitly
using a non-secure delegator object (which would be the
default if we allow any sort of extension to it to be
optional)? What about cases where there are multiple
delegators involved?
Anyway, it all comes down to this: if we don't have
something in place for mandatory, always-on entity security,
then why have any at all? It would be too easy to just
circumvent the security by not having a user passed down, or
by not going through the access controlled delegator... and
it's even worse if we have to change existing to get it to
do that because then it's not just malicious code that gets
through this way, it is also any code that we (or anybody
with custom code) misses when migrating. I'd rather have a
design that eliminates or at least mitigates that risk.
About the dependency issue, I'm not too worried about it...
that's just a matter of refactoring existing code, and no
matter how we support entity-level security some refactoring
and reorganizing of code will be necessary.
Anyway, I like the ThreadLocal ExecutionContext because it
can be a lower level object used for common information, and
it can be setup to just always be there, and if there are
multiple delegator instances used by a certain code block
they will all see the same ExecutionContext. Of course, with
that approach we still have decide how the system should
behave if no user is logged in... I suppose we simply hope
that a service or something else has run that the
anonymous/non-user is allowed to access and that it has
inherited permissions for things it calls... otherwise the
non-user will probably never have permission to touch an
entity.
One thing that crossed my mind with all of this, BTW, is
that maybe we should just not worry about the entity
security for now. We can implement it for other artifacts
and worry about the entity ones later on without affecting
the other stuff...
-David
On May 16, 2009, at 1:43 PM, Adrian Crum wrote:
I spent some time researching the GenericDelegator. I
think I have come up with a solution.
First off, there are more than 2,000 references to
GenericDelegator in the project. I'm sure there are many
installations that have customizations that reference
GenericDelegator also. Changing the GenericDelegator API to
accommodate the new security design is not a good idea - it
would break a lot of code.
There is also an issue with cross-dependency. Any
attempt to put security-related code in the GenericDelegator
will fail because the security component is built after the
entity component.
If we changed GenericDelegator so that we can make
per-thread instances of it, then the class could be extended
to add the new design functionality. All existing code would
still reference GenericDelegator, but it will actually be an
extended version that is security-aware.
I spent some time separating GenericDelegator's data
out and put it in a separate class called DelegatorData.
There is only one instance of DelegatorData per delegator
name. GenericDelegator holds a reference to a DelegatorData
instance, so everything still works the same. Now we can
have more than one instance of GenericDelegator.
We could extend GenericDelegator in the entityext
component to make it security-aware. That would eliminate
any cross-dependency issues. The dispatch context, request
handler, etc would create instances of the extended
GenericDelegator.
What do you think?
-Adrian
--- On Thu, 5/14/09, David E Jones <david.jo...@hotwaxmedia.com>
wrote:
From: David E Jones <david.jo...@hotwaxmedia.com>
Subject: Re: Brainstorming: Security
Requirements/Scenarios
To: dev@ofbiz.apache.org
Date: Thursday, May 14, 2009, 7:36 PM
I don't think there is a reason why we can't.
Why do a decorator object instead of just changing
the
GenericDelegator? In order for this to do anything
we'll
have to change EVERY call to a decorator method
anyway...
-David
On May 14, 2009, at 9:08 AM, Adrian Crum wrote:
David,
In the paragraph where you talk about the
ExecutionContext (a good idea btw) you mention
thread local
variables for the entities. On another Wiki page
you said
making the Delegator security-aware would require
refactoring the Delegator.
Why can't we have a user-and-security-aware
decorator
for the Delegator? The decorator could hold
the
thread's variables, and delegate the entity engine
calls to
the contained singleton delegator. All existing
code would
treat it like a regular delegator.
-Adrian
David E Jones wrote:
I have added these to the OFBiz Security
Refactor
page that Adrian started:
http://docs.ofbiz.org/display/OFBTECH/OFBiz+Security+Refactor
I also added a note that the
implementation
details I wrote up do not support scenario #3. I'm
not so
sure about how we're going to support that, but
I'm thinking
about it and if anyone has any ideas they would be
more than
welcome!
-David
On May 10, 2009, at 10:11 PM, David E
Jones
wrote:
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:51 PM, David E
Jones
wrote:
I think the discussion about the
"process"
versus "artifact" has resulted in consideration of
a
"process" as one way to group artifacts, so there
is no need
for separate items on this list that explicitly
handle
processes (ie they are handled implicitly). Please
let me
know if I'm misunderstanding that (especially
Andrew, you've
been a big proponent of the process side of
things).
On that note, are there any other
patterns
or specific security requirements that others
would like to
discuss? I don't think this is the sort of thing
where we
need to discuss the merits of each, unless someone
thinks
that we shouldn't bother with supporting any of
these
patterns. These should just be "socked away"
somewhere and
used while we're doing the design so we have
something to
evaluate the design alternatives to, and make sure
they
handle all of these scenarios (or that we decide
that a
non-supported scenario is not important).
-David
On May 4, 2009, at 11:28 AM, David
E Jones
wrote:
This thread is specifically
for
discussing security requirements and security use
scenarios
to drive OFBiz security functionality going
forward. Please
keep other discussion in another thread.
These things tend to fall into
two
categories: functionality access and record-level
access, or
a combination of both. That is a high level
generalization
so just warning you that what I list below may be
limited by
my own blindness since I usually think in terms of
those two
things for security configuration. In other words,
that's
the point of this brainstorming thread.
To get things started, here
are a few
I can think of and have heard from others, these
are in no
particular order:
1. User X can use Artifact Y
for
anything that artifacts supports and on any data
(where
"artifact" is a screen, web page, part of a screen
or page,
service, general logic, etc)
2. User X can use Artifact Y
only for
records determined by Constraint Z
3. User X can use any artifact
for
records determined by Constraint Z
4. Artifact Y can be used by
any user
for any purpose it supports
5. Artifact Y can be used by
any user
for only for records determined by Constraint Z
6. User X can use any artifact
for any
record (ie superuser)
Okay, you can see that my
initial pass
at this is sort of an enumeration of combinations
effort. If
you can think of other general scenarios, please
share!
Also, please feel free to share specific
requirements that
are not in such generic terms (we can worry about
putting
them in more generic terms like this later).
Thank You!
-David
