Alan, I think that all sounds great. We'll need to discuss your ideas, but I don't think it would be a bad idea for you to fork our Github repo at https://github.com/apache/incubator-openaz , make the changes you've recommended, and submit a pull request. I think it seems likely that we'll merge the changes.
I should also mention that we are desperately seeking more contributors! We're shorthanded, and if you or any other members of your team are interested in helping us make the 1.0 release, we'd be greatly appreciative. If you have any questions regarding how to get involved or what to do to help, please feel free to ask. Thanks! David Ash On Thu, May 12, 2016 at 4:35 PM, Alan Morgan <[email protected]> wrote: > Hello, > > I work for NextLabs and recently implemented the OpenAZ PEP api in Java > for the NextLabs PDP. Currently we provide a REST api and our own C, C#, > and Java interfaces, but movement towards a standard interface is obviously > a good thing and OpenAZ seems like the ideal candidate. At some point we > intend to make this code public. > > I have a few observations about the existing code design. Where possible > we tried to use the Std* classes "as is" in preference to writing our own > versions. I'm not sure if this was a design goal of OpenAZ or if the Std* > implementations are intended as references only, with no expectation of > reuse. Regardless, this proved to be rather effective and we were able to > re-use a number of classes. For the remainder, some obviously required a > NextLabs specific implementation, but for many others our implementation > was almost indentical to the Std* version, but we were unable to use/extend > the latter due to the classes being final or package visible. Specifically: > > > org.apache.openaz.pepapi.std.StdObligation is a simple wrapper around the > XACML Obligation type, but was not usable because it has package > visibility. Our implementation is identical. Perhaps it could be made > public? > > > StdPepAgentFactoryImpl is visible and almost exactly what we needed, > except that the engine returned by PDPEngineFactory is the default one and > this is not configurable. We changed > > pdpEngineFactory = PDPEngineFactory.newInstance(properties); > > to > > pdpEngineFactory = > PDPEngineFactory.newInstance(NEXTLABS_PDP_ENGINE_FACTORY_NAME); > > Perhaps StdPepAgentFactoryImpl could be modified to have a constructor > that takes a class name instead of properties (or a class name and > properties), calling the appropriate newInstance() method. > > > Our implementation of StdPepAgent is almost identical, only needing the > calls > > // Instantiate PepRequestFactory > pepRequestFactory = new StdPepRequestFactory(pepConfig, > mapperRegistry); > // Instantiate PepResponseFactory > pepResponseFactory = new StdPepResponseFactory(pepConfig, oRouter); > > changed to > > // Instantiate PepRequestFactory > pepRequestFactory = new PepRequestFactoryImpl(pepConfig, > mapperRegistry); > // Instantiate PepResponseFactory > pepResponseFactory = new PepResponseFactoryImpl(pepConfig, > oRouter); > > We couldn't extend StdPepAgent and overide this method, as it is final > (and package private). Interestingly, our implementation of > PepRequestFactory is almost identical to StdPepRequestFactory, the only > difference being the implementation of the newInstance() method (which > returns our own PepRequest). Our PepResponseFactory implementation is very > different from StdPepResponseFactory, however, so even if > StdPepRequestFactory were made configurable, we'd still need changes to > make StdPepAgent configurable. Whether and how to do this is open to debate. > > > Our implementation of PepResponse is nearly identical to StdPepResponse, > with some minor, predictable, differences (the implementation of > newInstance() being the major one). Alas, StdPepResponse cannot be > extended, so we couldn't use it. > > > We wrote some custom classes with their own mappers. Some of these classes > have attribute sets, so making them extend CategoryContainer seemed like a > good idea (then the mappers could extend CategoryContainerMapper). > Unfortunately, although CategoryContainer is public, its constructor is > not. Tantalizingly, CategoryContainerMapper is public with a public > constructor. > > > On the bright side, we were able to use, unchanged, the following classes: > > StdObligation (xacml) > StdObligationRouter and StdObligationHandlerRegistry > StdPepConfig > StdMapperRegistry and the various mappers > StdResponse and StdResult > StdAttributeAssignment and StdAttributeValue > > This made development of our own PEP interface much easier. I'd be > interested in a discussion about facilitating re-use of the existing > classes and approaches for implementing customer versions of the PEP api in > general (this existed for the OpenLiberty OpenAZ code, but the incubator > code is rather different). > > Thanks for your time. > > Alan > > --------------------------------------------------------------------- > STATEMENT OF CONFIDENTIALITY > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) and > may contain confidential or privileged information. No representation is > made on its accuracy or completeness of the information contained in this > electronic message. Certain assumptions may have been made in the > preparation of this material as at this date, and are subject to change > without notice. If you are not the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this e-mail and > any attachment(s) is strictly prohibited. Please reply to the sender at > NextLabs Inc and destroy all copies of this message and any attachments > from your system. > ======================================================================
