[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Policy Distribtion
I made an addition to the first link below on the Wiki. I’d like to see this move forward.
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 Cohorts in each of these contexts, or I could equally have a single Cohort that is active in two different contexts. Within a software release cycle, I might have a new Policy Cohort active in Development, Integration (SIT), and User Acceptance Test (UAT). Before testing is complete, I would expect a previous Policy Cohort to remain in the Production PDPs; during deployment, I would expect the new Policy Cohort 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 Cohort 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.
In response to the discussions that arose from early drafts of the REST profile, I created this wiki page describing what I believe the architecture of the PAP.
Much earlier, I made more specific proposals for a protocol to distribute policies to PDPs from a repository. This discussion is Issue 62.
At the time that was written the protocol was intended to be XML/SOAP, but it could as easily be REST/JSON. I think the pull protocol could be specified directly from the outline given.
However, in my mind the critical thing is to get agreement on the various abstractions relating to the architecture. Once we have that, I believe it is a simple matter to construct one or more protocols with the required properties.
Here is a short summary of my thinking.
What a PDP needs to do is not just get some policies, but specifically get the set of policies that are supposed to be in force for it at a particular point in time. I coined the term Cohort to refer to such a set of policies. The cohort is also the unit of testing for obvious reasons. The same policy can appear in different cohorts, but its effect may be completely different because of the other policies in the cohort. Since different PDPs may use the same or different cohorts, there also needs to be scheduling information which says which cohorts should be in force on each PDP at particular times. My assumption is that any XACML system will have something equivalent to these concepts already, including the ability to administratively configure cohorts and schedules.
If we do not address the entire set of capabilities, I don’t think we need to define a profile at all. If the goal is simply to move policies identified by policy ID & version from point A to point B then we can simply pick an existing protocol such as FTP, NFS or SMB and be done with it.
The scope of policy distribution in my view should be limited to the interaction between the part of the repository which contains cohorts of policies which have been created, tested and are ready to go to production. I don’t want to constrain the design of any system for policy authoring, testing, analysis and audit.
I ask everybody to take a look at my proposed architecture. Is it sufficiently close to how your product works that a standard protocol to allow PDPs to obtain the policies they need from a repository would be something you would consider? Is the architecture missing anything it should contain? Is your architecture different in some way which would make this scheme irrelevant or not useful?
An important requirement that needs to be agreed on is whether the PDP pulls policies or the repository pushes them or do we need both.
Originally I thought a push protocol was the right model because the repository knows when there is a new cohort to be distributed. However it turned out that the pull protocol is a little easier to design. Also embedded PDPs may not be configured as servers (able to accept asynchronous requests) at all. If having the PDP poll the repository for updates is not satisfactory, we could probably define some kind of reverse channel to alert the PDP to check for updates.
My intention is that the pull protocol works like this: PDP gets its own schedule. PDP gets the cohort lists for the current and future cohorts. PDP asks for policies it does not already have. Polices appearing in multiple cohorts only have to be obtained once.
The only real assumption (aside from the policy id & version uniqueness specified in core) is that any policy is small enough to fit in a response message. In practice I think the whole cohort will be transferred at once.
What do you think? Is a pull protocol sufficient or do we need both? If we do pull, is a reverse notification required?
Other than the above I don’t think there is anything else needed for me to propose a specific protocol. Is there anything else we need to settle?
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.