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.
======================================================================
