RE: [xacml] Proposed PAP Architecture

[Jean-Paul Buu-Sao <jean-paul.buu-sao@tscp.org>]

Hal,

a) On configuration management: even in the simplest case an autonomous policy (that can exist outside a Cohort) is subject to change. It can be stored in the repository under a given version, and then another version is produced, which as well will be stored in the same repository. This is what I meant by the configuration management function of the repository. Side note: there are use-cases where multiple versions of a policy must be active at a given point in time. But this is for another discussion.

b) You are correct, it is not XACML specific, just a different flow which, however could imply new requirements around trust (just because this policy, or policy Cohort, comes from a PAP of a different administrative domain). How about keeping these use-cases as placeholders?

c) I think that the concept of Cohort, as you defined it on the Wiki page, is a very important one. We at TSCP define the concept of a protection profile, that represents a set of policies that are all meaningful for a given business context. The enclosed policies can (and do) come from different policy authorities, can exist in a fairly large number (say, hundreds) and need to be validated ahead of execution is such a way to minimize the risk of conflicts (or contradictions) at run time. We know that conflicts will occur, but want to limit the risk. The concept of Cohort, IMO, directly maps to our concept of protection profile. Hence the need to ensure consistency of a Cohort.

Regards,
Jean-Paul Buu-Sao

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@oracle.com] 
Sent: Thursday, June 14, 2012 17:13
To: Jean-Paul Buu-Sao; xacml@lists.oasis-open.org
Subject: RE: [xacml] Proposed PAP Architecture

> 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
>