Re: [xacml] New Topic: Closely Coupled PEP/PDP

[Prateek Mishra <prateek.mishra@oracle.com>]

Hal,

As discussed on Mar 1 conference call, we are interested in the creation of
a language-specific authorization API that could interact with a XACML 
PDP. We can work
out the exact forum where this work should take place, certainly the 
XACML TC
is a reasonable choice. We should probably have a broader discussion in 
this space, including
for example, the possibility of an open source implementation.

Regarding the issue of optimization via the return of generalized 
results from a PDP, while this could be
left at the vendor level, it may be be helpful to provide a profile that 
articulates some of the
issues here.

- prateek


> Prateek asked:
>
> (2) Is there a performant PEP--> PDP protocol?
>
> The main challenge here is performance
>
> Some applications need to make 100s of authorization decisions with low
> latency requirement
>
> It may not be acceptable to make a network call for each authorization
> decision
>
> XML Marshalling and unmarshalling of <RequestContext> and
> <ResponseContext> may be too expensive
>
> Strategies to lower costs
>
> Define a language-specific binding for the authorization interface
>
> Should we pursue a JSR in this space?
>
> Other ways of minimizing costs include returning generalized results to
> the PEP and caching
> ----------
>
> As discussed above, there is no requirement to instantiate the request
> context as XML. Therefore this is not a performance limitation.
>
> A closely coupled PEP/PDP has always been an option in XACML. In fact
> the SAML profile req/resp protocol was a bit of an after thought.
>
> To define a closely coupled method of calling a PDP requires specifying
> a programming environment. I gather that what you have in mind is a Java
> API. There is some history here. Take a look at JSR 85.
>
> JSR 85 was not approved, but it led to JSR 115, which is quite usable to
> call an XACML PDP. WLS supports this today. However BEA has defined a
> series of security SPIs, including one for Authorization. The
> specifications are publicly available. A number of vendors have built
> providers which use this SPI. BEA contributed some of this material to
> JSR 196, so I believe we would be willing to contribute more to a
> standardization effort. I don't see any reason this could not be done in
> the XACML TC which has more favorable (and much simpler) IPR
> considerations.
>
> Obviously various kinds of optimizations and caching strategies are
> available to implementers. These have generally not been standardized
> because they do not effect the interfaces between components and because
> we wanted to allow for product differentiation opportunities.
>
> Hal
>
>