+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 > > >
