[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New Topic: Closely Coupled PEP/PDP
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]