On Jul 9, 2009, at 9:40 AM, Adrian Crum wrote:
I'm bumping this because I would like to begin working on it.
I've been updating the design document when I have time - http://docs.ofbiz.org/x/Ch8
.
There are two design issues that I would like to get finalized soon,
so that work can begin:
1. The document proposes converting the Security abstract class to
an interface, and adding new methods to the interface that will
implement the new security design. If there are no objections to
changing Security to an interface, then I will design and document
the new Security API.
What would go in the new security API? Isn't the idea to externalize
this and make it configurable?
2. The document describes two artifact hierarchies - static and
dynamic. The pros and cons of each is demonstrated in the Access
Control Scenarios portion of the document. We need to decide which
approach to use. Once that decision is made, we can build out more
of the design.
In the examples you've done for static and dynamic I don't think the
dynamic ones really show how it is meant to be used. What I mean by
that is that the point of the dynamic ones is that the "path" as it
were doesn't depend at all on where the artifact is located, it only
depends on how the artifact is referred to or "invoked" at run time.
In fact, to be frank, I don't think there is any reason we should
consider not using the "dynamic" method. There are a couple of big
problems I see with the current security, or the most common complaints:
1. you have to modify "code" (usually XML files) to change how
permissions are used and which are available
2. the current permissions checking at runtime limits reuse of
artifacts because the permissions are often determined by artifact and
you can't change the permission (implicitly or explicitly) when the
artifact is used in another application that has a different security
setup (and/or you don't want to give users permissions to the base
applications)
The solutions to these are:
1. configure permissions in the database and not directly in
artifacts, or even in configuration files independent of artifacts
2. use the "dynamic" way of determining the context for an artifact
instead of using where it is located for the context
BTW, to do this one thing that will need to be done is to implement
the "ExecutionContext" object, and on that note I think that will help
with the multi-tenancy and deployment flexibility things that have
been discussed on the list recently (especially by Marc and Henning).
The idea is that nothing would keep a local reference to the delegator
or dispatcher, not even the service engine, control servlet, and other
framework components too.
-David
Adrian Crum wrote:
--- On Sun, 5/17/09, David E Jones <[email protected]>
wrote:
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...
It fits into the design objective because it takes the record-level
filtering out of code and puts it in assigned permissions. Isn't
that one of the objectives? Remove the security checking that is
embedded in code and put it in the database where an administrator
can assign it to a user.
Instead of hard-coding record-level permission checking inside some
other service, extract the record-level permission checking code,
make it a service, and assign the service as part of a user's
permissions.
It's clear we have disconnected somewhere. The existing entity
engine doesn't know about security. It works with not-logged-in
users and anonymous users and whatever else comes along. I'm not
suggesting we change any of that. Keep it all the same. But add the
ability to restrict records based on the user. If there is no user,
then it does what it has always done. I don't know how else I can
say it. *shrug*
-Adrian
