Architecture of Policy Administration Point (PAP) and related components

Note: XACML Core treats the PAP as a single entity which is the source of Policies. I propose that we agree upon a general architecture which identifies the sub-components of the PAP, their functions and interfaces. Once we have some agreement we can agree on specific protocols and interfaces to support this architecture, with some hope of overall consistency.

Here is my initial attempt at this. I have tried to define the absolute minimum I consider necessary. My hope is that more advanced functions can be implemented either as internal functions within the agreed upon components, or, if necessary, more powerful protocols can be added later to enable them. -Hal-

Statement of requirements

  1. A PAP must be able to support multiple PDPs, with distinct sets of active policies.
  2. The same Policy may be used in multiple active sets used by different PDPs.
  3. Multiple PAPs with either identical or different stored Policies supporting the same or different PDPs for reasons such as availability or performance may be deployed.
  4. A PAP should enable PDPs to obtain sets of active policies in advance of their validity time and switch to using them when they become effective and without any interruption in service.

Proposed definition and requirements: (From Issue 62) A Policy Package (or Package) is a set of policies (and/or policy sets) which are intended to be in force at a given time. Under XACML 3.0, a Policy Package may include both Administrative and Access Policies. However, a Policy Package does not include just-in-time policies which are delivered with a decision request and in force only for the duration of that request. A Policy Package is typically tested as a unit and distributed as a unit.

  1. Identity: must be uniquely identifiable, under the namespace it is associated with.
  2. Authenticity: an issuing authority may be associated and be authenticatable at a level of assurance by external (e.g. XML signature) means.
  3. Integrity: integrity may be ensured using appropriate means (e.g. XML signature).
  4. Confidentiality: confidentiality may be ensured using appropriate means (e.g. XML encryption).
  5. Reference-trust: policies included in the Package may contain references to external attribute providers, for which the container Package must ensure trust (e.g. in this case it must call them out).
  6. Administrative attributes: may be added, in a flexible manner, to allow expression of e.g. business context information, contact information.
  7. Versioning: ?.
  8. Self-containment: a policy package is self-contained, in the sense that it contains all the artifacts that it needs to operate.
  9. Auditability: a policy package must be considered as an unit of audit, i.e. audit log events must refer to the package, in addition to the policy that triggered the authorization decision.
  10. Testability: a policy package contains test dataset that consumers / implementors can use in order to test against their own implementations.
  11. Validity: a policy package may be only valid between a start date/time and an end date/time (either boundaries can be omitted) to Bill's point

it seems that a TTL would be useful here as well. --bill

PAP Sub-components

Repository

Policy Authoring Function

This function allows creation, modification, and deletion of Policies and Policy Sets. It essentially needs access to a CRUD interface to Policies & Policy Sets and Policy Metadata, if any. This function may support more complex functionality, such as Source Code Control style primitives such as checkout, checkin, compare, branch, merge, restore superseded versions, etc. This function also allows creation, modification and deletion of Package Lists. Here again CRUD operations on Packages is sufficient.

Policy Testing & Analysis Function

This function allows Packages to be tested and analyzed by automated tools. It needs read access to Policies and Package Lists. Additional information required by these tools, such as test inputs and expected results is unspecified. Test functions may include staging PDPs.

Policy Distribution Function

This function is responsible for distributing policies to PDPs. It needs read access to Policies (& Policy Sets) and Package Lists. It needs to be able to create, modify, and delete PDP Package Schedules. It may support PDP pulling Policies or pushing Policies to PDPs or both. If only pull is supported, a mechanism to inform PDPs that new policies are available may be required. The transfer scheme should require that only policies that the PDP does not yet have be transmitted.

Policy Decision Point (PDP)

The PDP is not a part of the PAP, but obviously it is a consumer of policies. The PDP may maintain unexpired Policy Packages in local non-volatile storage or obtain the currently active Package at startup time. PDPs with non-volatile storage should obtain any Packages scheduled for future activation to enable uninterrupted operation. When a new Policy Package goes into effect, decisions in progress should continue to use the old Package. New decisions should be based on the newly active Package.

Open Issues

  1. PDP Package Schedule end time - Do we need it?
    • Ray: I don't think we need it
  2. Repository handling of Policy Ids

Discussion

[David Laurance] I see requirements to deploy PDPs into different contexts. The simplest example is that we might have different PDPs in Development, SIT, UAT, and Production environments. At one point in time, I could have different Policy Packages in each of these contexts, or I could equally have a single package that is active in two different contexts. Within a software release cycle, I might have a new Policy Package active in Development, Integration (SIT), and User Acceptance Test (UAT). Before testing is complete, I would expect a previous Policy Package to remain in the Production PDPs; during deployment, I would expect the new Policy Package to become active in Production.

My smaller point is that the effective date is context-dependent. The larger point is that we're off to the races in the world of versioning and version delivery, and it's worth thinking about how artifact versioning should be modeled more generally. I think the Policy Package as described above makes sense, but we need to integrate it into the XACML architecture in a way that fits into the larger deployment puzzle.

Policy Administration Point Architecture (last edited 2015-03-12 14:38:18 by hal.lockhart)