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
