[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Policy Distribtion
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. https://wiki.oasis-open.org/xacml/Policy%20Administration%20Point%20Architecture Much earlier, I made more specific proposals for a protocol to distribute policies to PDPs from a repository. This discussion is Issue 62. https://wiki.oasis-open.org/xacml/IssuesList 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? Hal From: Hill, Richard C [mailto:Richard.C.Hill@boeing.com] Is the approach to make the PAP the gateway to the PRP? Will the PAP orchestrate the policy sync, update, distribution, etc regardless of the PDP vendor implementation? Maybe we can develop some use cases to facilitate the discussion and agree on the approach. I would be happy to help with that. From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Sinnema, Remon Hi David, The consensus at the time was that I described an API for something that wasn’t standardized, so the standardization had to come first. I’m glad to see that we’re now getting to that. Once we’ve established a standard way of distributing policies, I’ll be happy to add an API for that to the REST profile. Thanks, Ray From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of David Brossard Hi Richard, everyone, In Ray's initial REST draft, he included a standardized PAP API. I believe this was axed later. I think we should revisit that effort. Thoughts? On Fri, Aug 23, 2013 at 8:06 PM, Hill, Richard C <Richard.C.Hill@boeing.com> wrote: As I mentioned on yesterday's TC call, it's starting to be become apparent that large companies and multi-agency government entities will need a standard way to distribute XACML policies (e.g. sync updates from a centralized policy repository point to PDPs). The XACML 3.0 specification, section 2.9 Policy distribution, leaves policy distribution implementation to XACML product companies. Understandably, these implementations may be fine tuned to work well with one company's XACML products, but may not with another company's XACML products. Additionally, it cannot be guaranteed that each org in a large company or all government agencies will use the same company's XACML products. I believe that without a standard approach to distribute, sync, etc, XACML policies it may become a barrier to XACML adoption. Hal Lockhart stated, on the TC call, that he has started work on trying to standardize this in the past and has taken the action to revive this effort. I would like to help with this and I encourage other to participate as well. Hal, Is there a link on the Wiki on your past policy distribution work? Thanks, Richard -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]