--- 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 <--> ??? > > 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. I agree. I'm not understanding what you have pictured, and I mentioned that in an email and asked if you could update the scenario detail to be more accurate. > 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. 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. > 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) I agree with both of those. That's why we're having this discussion. :-) > The solutions to these are: > > 1. configure permissions in the database and not directly > in artifacts, or even in configuration files independent of > artifacts Agreed. > 2. use the "dynamic" way of determining the context for an > artifact instead of using where it is located for the > context Again, I must be missing something. It seems to me this will make things more complicated than they need to be. > 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. I know you're really busy, but I think it would really help me (and possibly others) understand your vision of the security redesign if you could improve the access scenario detail pages by fleshing out the dynamic hierarchy part. Thanks for the reply and comments! Just so there is no misunderstanding, I'm not going to rush off and start doing anything until it is settled on the mailing list, and marked as finalized on the design document. -Adrian
