[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Outline of Policy Distribution Protocols (Issue 62)
Here is an overview of a scheme for distributing policies. It is designed to work with any version of XACML. If it seems reasonably sound, I will create a Profile with specifics and Schema. I have also posted this text to the wiki under Issue 62. Hal -------- XACML Policy Distribution Assumptions There is a Policy Administration Point (PAP) which holds all the policies for some domain. There are a number of Policy Decision Points (PDP) which retain in some local (typically non-volatile) storage all the policies it considers to make decisions. Different PDPs may use different subsets of the policies held by the PAP. A PAP will typically serve a number of PDPs. Conceivably a PDP may get its policies from several PAPs, however I am not aware of a motive for this usecase. This protocol is concerned only with the interaction between one PDP and one PAP. It is assumed that the PAP knows what policies a given PDP should get by some unspecified means. In a real deployment, this might be based on manual configuration, some portion of the policies such as their Targets or by some other means. It is assumed that each PDP has a unique identifier which the PAP knows in advance. The protocol should make it easy to recover from failures of either participant or the communications link. Also in most cases work done prior to a failure should not have to be repeated. The protocol should make it possible for the PDP to determine that it has a complete and consistent set of policies. All XACML Policies and Policy Sets contain an identifier. Different policies can contain the same identifier, but they will have different date/times. The combination of Policy Identifier and date/time is assumed to be unique. For the purposes of this discussion the Id & date/time pair are called a Policy Id. Two different protocols are defined, a push protocol (controlled by the PAP) and a pull protocol (controlled by the PDP). Both protocols have different advantages and disadvantages. It is expected that each will be used in different environments. Push Protocol 1 Req. (Optional) PDP -> PAP request policy update. This message will be useful in cases such as a PDP first starting up. 2. PAP -> PDP request current policy list This can be sent in response to an update request or as an unsolicited message. A PAP might initiate the request because an Administrator has updated the policies. 2. PDP -> PAP response with list of Policy Ids currently held by the PDP. Optionally the PDP can specify a maximum message size for policy updates. PAP compares the policies held with the list of policies the PDP should hold. 3. PAP -> PDP Policy update batch. The batch contains two kinds of items: A. Delete policy - specifies the Policy Id of a Policy to delete B. Add policy - contains Policy or Policy Set to add (Batch mechanism TBD. Could use SPML batch function or WS-RM sequence.) Each message in batch should be acknowledged. PDP should implement atomic update. No action should be taken until complete batch is received. Once batch is complete, policy evaluation should cease. All deletes and adds should be applied. Then evaluation should resume. Pull Protocol 1. PDP -> PAP Request current policy list 1. PAP -> PDP response - list of current policy ids for that PDP PDP compares list with policies currently held. Policies to be deleted are noted. 2. PDP -> PAP Policy request - list of Policy Ids of policies to be returned 2. PAP -> PDP Policy response - Returns Policies and Policy Sets. PAP is allowed to send subset of Policies requested. If a requested policy does not exist, an error must be returned identify the Policy in question. In this case, the PDP should go back to sending a request for the current policy list. PDP continues sending policy requests until all needed policies have been received. Then the PDP stops evaluation, atomically adds new policies and deletes obsolete ones, then resumes policy evaluation.