Cool. I started working on some of the execution context code. Both
this and the security changes look like they'll involve some major
refactoring and wide-spread changes, so I'm planning to get a branch
going. I'll commit what I've done so far soon (hopefully later today).
-David
On Jul 13, 2009, at 10:31 AM, Andrew Zeneski wrote:
+1 on abstracting the Authorization API.
+1 on dynamic hierarchies
I should have some time to knock out some of this code too, so I am
happy to coordinate with whom ever takes the lead.
Andrew
On Fri, Jul 10, 2009 at 3:03 AM, David E Jones<d...@me.com> wrote:
On Jul 9, 2009, at 9:36 PM, Adrian Crum wrote:
--- On Thu, 7/9/09, David E Jones <d...@me.com> wrote:
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?
One of Andrew's goals was to make the OFBiz security
implementation more
compatible with third party authorization software - a goal I am
100% in
agreement with. I was picturing (and I thought I made this clear
in the
document, but maybe it needs more work) having a Java interface
with a set
of methods that would define a security API. The artifacts would
interact
with that API. The idea is to decouple the implementation of
security. The
interface's implementation might use OFBiz entities, or Andrew's
Cloud, or
LDAP. The artifacts won't know the difference - they only see the
API.
Artifact <--> Authorization Manager API <--> ???
You're talking about authorization and not authentication, right?
Are there
any standards for authorization that we could implement to? (I'm
not aware
of any...)
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.
The reason I see a problem with that approach (and I'm not trying
to be
argumentative, just trying to make sure we understand each other's
concepts)
is there could be hundreds of execution paths leading to an
artifact. Each
of those execution paths would have to have permissions assigned
to them.
I'm not sure if you'd ever want to do that. The general idea is
that you
specify permissions for a particular artifact and generally you'd
say it is
an "inheritable" permission so that anything the artifact refers to
or calls
would inherit the permission and not need one of its own.
With the stuff I wrote up you wouldn't typically even have
permissions for
individual services, and sometimes not even for screens. More
commonly you'd
grant permission to a webapp, a decorator screen, etc. If you want
to you
could do lower level permissions but most of the time it simply
wouldn't be
desired or necessary.
In the static hierarchy, the Authorization Manager doesn't care
how you
got to an artifact, it only cares about what your permissions are
once you
get there.
For lower level artifacts isn't how we go there more important than
the
permissions on the artifact itself? For example, a screen may be
used in
more than one application and we probably care more about the
application
(or part of that application) that it was rendered in than we do
about that
particular screen. If we do care about the particular screen we'd
probably
still want different permissions depending on which application it
was
rendered in.
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.
Now that I have written a servlet for the iCalendar integration, I
know
exactly what you're saying here. And I agree 100%. Even if we made
that
change without the security redesign, it would be a huge plus for
the
framework.
Yeah, one way or another this lower-level object should (and
hopefully soon
will!) be implemented. It wouldn't depend on the security changes
and the
new security stuff could/would use it.
-David