OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] Policy Distribtion

Perhaps I made an error in specifying that policy cohorts would have a validity interval. If you look carefully, you will see that there are 3 important information objects: Policies (including PolicySets), Cohorts and PDP Cohort Schedules. The idea is that policies are assembled into to cohorts and unit tested for basic operation. Subsequently PDP schedules are made up to indicate what policies should be in force at any particular PDP at any point in time. It is the validity intervals in the PDP Cohort Schedules which matter. I believe this scheme meets all the requirements you have given below. Different PDPs can have the same cohorts or different ones. The validity interval for a policy or cohort which no PDP is using, is at best moot and probably should not exist at all.


I expect that the initial phase of unit testing, before the cohort is even known to be functional will not involve the use of the distribution protocol. More likely you would use a PDP in a test framework to do what-if testing and regression analysis, along with other techniques such as static analysis. However, once cohorts have been unit tested they can be scheduled for PDPs in environments for development, SIT, UAT or production. You will be able to schedule any given PDP to use any given cohort for any time interval. It will also be possible to implement staging cohorts to a PDP to switch over at a specified time.


I hope and expect to see a lot of innovation around the phase prior to unit test completion, so I do not want to constrain this process to operate in a specific way. In particular, I want the distribution protocol to be agnostic about the way versions are used by different tools or organizations. For the purposes of distribution it is sufficient to know that ID + version uniquely identifies any policy.


For example, I personally think that having two policies with the same id and different versions in the same cohort represents bad practice, but I do not think the distribution protocol should enforce this.


Please let me know if you are aware of requirements which cannot be met by the proposed scheme.




From: Laurance, David C [mailto:david.c.laurance@jpmorgan.com]
Sent: Tuesday, October 01, 2013 10:33 AM
To: Hal Lockhart; Hill, Richard C; xacml@lists.oasis-open.org
Subject: RE: [xacml] Policy Distribtion


Hal, all,


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.





From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Hal Lockhart
Sent: Tuesday, August 27, 2013 2:54 PM
To: Hill, Richard C; xacml@lists.oasis-open.org
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.




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?




From: Hill, Richard C [mailto:Richard.C.Hill@boeing.com]
Sent: Monday, August 26, 2013 11:14 PM
To: xacml@lists.oasis-open.org
Subject: RE: [xacml] Policy Distribtion


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
Sent: Monday, August 26, 2013 7:21 AM
To: David Brossard (david.brossard@axiomatics.com)
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] Policy Distribtion


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.







From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of David Brossard
Sent: Monday, August 26, 2013 3:25 PM
To: Hill, Richard C
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Policy Distribtion


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.




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?





David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]