RE: [xacml] Bindings and frameworks for PEP to PDP access

["Hal Lockhart" <hlockhar@bea.com>]

This was discussed on the last call and after some discussion of Java,
Anil suggested that perhaps we could specify a language independent API.

I have been thinking about this, but my conclusion is that the XACML
Request and Response Contexts do in fact specify a language independent
API. Since the spec says that it is not required that they be
instantiated as XML documents, that means implementations are free to
map them (and some invocation mechanism) to the mechanisms and data
types of Java, C++ of whatever language needs to be supported.

I believe Prateek's motives are to provide better performance while
retaining the interoperability of the SAML decision request protocol.
IMO this will only be obtained by specifying language specific
datatypes, etc. in detail.

Anil, did you have something else in mind?

As an additional requirement, I believe that applications per se should
not be making calls to the PDP. I think that in ordinary cases the
container should act as the PEP and collect the inputs and call the PDP.
This applies whether the container is J2EE, Servlet or .Net. 

Hal

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
> Sent: Thursday, September 27, 2007 9:17 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Bindings and frameworks for PEP to PDP access
> 
> This is an issue that was discussed at the f2f and was also featured
as
> case 2.1.1 of the interop.
> 
> Its been some time since we discussed this issue, so I will first
point
> to the relevant text from the f2f.
> 
> http://lists.oasis-open.org/archives/xacml/200703/msg00071.html
> 
> [quote]
> C: closely coupled PEP/PDP
> ...
> D: PEP/PDP issues: how do you know what inputs the policies refer to?
> ...
> [\quote]
> 
> The starting point of the analysis here is to understand three
distinct
> roles that are involved: (a) application developer
> (b) deployment manager (c) policy manager.
> 
> The application developer inserts call-outs to the XACML engine and
> processes results as returned from the PDP.
> This follows the model in Section 2.1.1. of the interop document.
> 
> At the F2F it was suggested that JSR #115 satisfies these requirements
> but a quick analysis of JSR #115 shows that while
> it allows for a policy engine to be connected to a java container but
it
> doesn't expose key XACML functionality.
> 
> Some of the gaps include:
> (i) ability to pass arbitrary environment, resource and action
attributes
> (ii) ability to process returned values from the PDP - especially
> obligations.
> 
> One additional constraint that should be noted here is that
application
> developers may not be aware of all the information
> required for the authorization call-out. The reason for this that
> policy's are created by policy managers, and this information
> may not be available when the application is being developed.
> 
> The deployment manager interacts with the PDP and PEP (in this case
the
> application) to create the appropriate linkages.
> At this stage adequate information may be available to complete the
> linkage between the two. Specifically, the deployment
> manager requires:
> 
> (i) what requests are being made from PEP and what attributes are
> currently being transferred
> (ii) Which policies at the PDP are relevant to the PEP requests, and
> what attributes should be included in the requests originating from
the
> PEP
> 
> So some form of reconciliation is needed at this point, especially one
> that does NOT involve re-coding/re-building the PEP but
> rather extending it so that all required attributes become available.
> There may also need to be a certain amount of coordination between
> the deployment manager and the policy administrator.
> 
> SUMMARIZING: I have described a use-case that we have found quite
> significant and which was one of the two scenarios
> demonstrated at the interop. I would be interested in feedback on the
> use-cases and any comments on standards and frameworks available to
> solve these cases.