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

[Anil Saldhana <Anil.Saldhana@redhat.com>]

Hal,
  the use case is the construction of policies, requestctx and 
responsectx objects. 
- Every implementation is going to have its own API (irrespective of 
programming language) in the construction of these three objects.
For example: I would like to programmatically construct a 
Policy/PolicySet instance and pass it to the PDP.  Similarly,  PEP 
implementors will need to use some proprietary API in constructing the 
R/R context objects.

I do not think that this topic is critical at the spec level but good to 
have.

Regards,
Anil

Hal Lockhart wrote:
> 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.
>>     
>
>   

-- 
Anil Saldhana
Project/Technical Lead,
JBoss Security & Identity Management
JBoss, A division of Red Hat Inc.
http://labs.jboss.com/portal/jbosssecurity/