Supporting third-party PEPs communicating with XACML policy engine

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

This note describes a deployment scenario that we are increasingly 
encountering.
It highlights some area where we believe XACML 2.0 may need extension.

We describe the scenario using terminology taken from Sec 3.1 of 
[xacml-2.0-core].

SCENARIO
-------------

An enterprises utilizes a variety of applications and COTS to access 
resources.

Each component includes an embedded PEP for access control. Some 
components may include some resource management aspects
and so include some part of a context-handler as part of the PEP 
('enhanced PEP").

New components and devices with embedded PEPs are being acquired by the 
enterprise over time.

The enterprise has an existing access control policy infrastructure 
based on XACML, including one more PDPs.

(1)
What protocol should the enterprise require the PEPs to implement? One 
strategy is to use the <saml:XADQ> and
<saml:XADS> over SOAP ([xacml-saml-profile] or just <xacml:Request> and 
<xacml:Response> elements within a SOAP envelope.  But in
many situations this is too expensive, especially when fine-grained 
authorization decisions are involved.

What advice does the TC have for enterprises in this context?

(2)

<xacml:Request> and <xacml:Response> elements are pretty general 
containers with the following characteristics:
(a) <xacml:Request> may carry an arbitrary number of resource and 
subject elements,
(b) Each of subject, resource, action, environment elements may carry 
standard attribute values or application/domain specific vocabularies
(c) <xacml:Response> element may carry obligations
(d) In theory, the PDP and PEP may participate in a multi-step exchange, 
though we havent seen this in practice

Deployment of PEPs would be made much easier if PEPs include a detailed 
escription of the information under (a), (b), (c) and (d).
This can be also be viewed as a form of  meta-data associated with a  PDP.