OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: New Topic: Closely Coupled PEP/PDP


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]