RE: [xacml] Proposed PAP Architecture

[Hal Lockhart <hal.lockhart@oracle.com>]

> I suggest that we add:
> 
> a) Repository: configuration management (possibly offloading some of
> the configuration management under discussion with the REST profile)

I am not quite sure what you have in mind here. Other than having some sort of list of PDPs, in my model pretty much the only aspect of configuration management in scope is creating PDP Cohort Schedules. I have specifically avoided management functions which would surely exist in any real deployment, such as starting and stopping PDP servers, assigning PEPs to particular (networked) PDPs, configuring PDP operational parameters, etc. 

I don't see the need to standardize this stuff because: 1) different implementations will do it in different ways and I see no pressing demand for interoperability and 2) there are many existing standards relating to system and network management which should be able to handle non-Access control configuration issues. I am trying to concentrate on the part which is specific to XACML: having the right policies at the right place at the right time.

> b) Policy Distribution Function: distribution of policies between PAP.
> This way the model support "horizontal" distribution (between multiple
> PAP, typically of different administrative domains) together with
> "vertical" distribution (between a PAP and multiple PDP, typically of
> the same administrative domain).

Well I was trying to keep things as simple as possible. PAP to PAP communication is even less well understood than the rest of this stuff. I see two use cases for PAP to PAP flow of policies. 1) Replication for redundancy. I think this can be dealt with adequately with existing standardized and proprietary mechanisms. I don't see anything XACML-specific about this case. 2) Selective reuse of some policies. I was kind of assuming this case would have to be under specific human control and that whatever protocols or interfaces we defined to support policy authoring would be sufficient for this.

Do you have other use cases in mind?

> c) Some kind of "Cohort Authoring Function": I believe that creating a
> consistent and workable Cohort is not trivial activity that "Policy
> Authoring" alone can support, as some consistency needs to be
> guaranteed within a Cohort (I assume that your proposed Policy
> Authoring Function essentially considers one policy at a time).

I think generally policies will be created under some sort of framework or template which presumes the policy fits at a particular point in a policy tree. Therefore defining a Cohort should consist of simply specifying the particular policy instances which comprise the cohort and running test cases against it to see if the expected results are obtained.

I agree that policy and cohort definition is a little understood art at this time. I am simply trying to define a minimal set of components and data which will allow parts of such a system to be standardized.

Please tell me more about how you envision these things working. I would be glad to add anything to the architecture that the TC feels is needed.

Hal

> 
> Regards,
> Jean-Paul Buu-Sao
> 
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Hal Lockhart
> Sent: Wednesday, June 13, 2012 00:31
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Proposed PAP Architecture
> 
> I have added a new page to the wiki to develop an agreed upon minimum
> architecture for the sub components of the Policy Administration Point
> (PAP).
> 
> https://wiki.oasis-
> open.org/xacml/Policy%20Administration%20Point%20Architecture
> 
> I believe that if we can come to agreement on these components and
> their functions, it will provide a solid basis for defining the
> necessary protocols and interfaces.
> 
> Please take a look and make comments or modifications.
> 
> Hal
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>