On May 17, 2009, at 7:32 AM, Adrian Crum wrote:
A common request that appears on the mailing list is the ability to
filter records depending on the user. Let's say a salesperson can
only see customers they are assigned to. Currently, you can filter
on Party Role so the salesperson gets a list of customers, but that
won't restrict the list to only that salesperson's customers.
A filter could be created that filters out customers related to the
salesperson, and that filter could be assigned to the Party entity
in the salesperson's permissions.
Currently authentication in OFBiz is done in 2 very distinct ways, and
I often talk about the distinction with the terms artifact-level and
record-level permissions.
If I understand correctly what you are describing above it is simply
record level permissions. And yes, I agree that is a common
requirement that we've discussed quite a bit. I'm worried I'm
misunderstanding though because I'm not sure how that fits with
comment...
If the salesperson isn't logged in, then they aren't going to see
anything anyway.
Yes, probably true for a salesperson... but what about an ecommerce
customer or other cases where they probably won't have any explicit
permissions, just implicit authorization based on a direct record-
level connection (ie any user can change their own contact info type
of rule that is currently implemented in code)? In those cases there
may be no user passed down, or it may be a dummy user like the
"anonymous" user, but they still need to perform various operations.
-David
--- On Sun, 5/17/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: Sunday, May 17, 2009, 1:26 AM
Isn't that the opposite of what we want? Things should be
more
restricted if there is no user, and not less restricted. I
may be
misunderstanding what you mean by this though...
-David
On May 16, 2009, at 6:28 PM, Adrian Crum wrote:
The idea I had in mind was having the ability to
assign a filter to
an entity for access control scenario 3 - http://docs.ofbiz.org/x/
JR8. If a user isn't logged in then there is no filter
assigned to
the entity, so it operates normally.
Btw, I'm not going to write any code until we get all
of the details
worked out and finalize the design.
-Adrian
--- On Sat, 5/16/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: 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
