Subject: RE: [xacml-users] XACML 3.0 Obligations
It seems you could equally well argue that the PEP has no way to enforce that the PDP uses the correct policies or evaluates them correctly.
Obligations and Advice are generally considered extremely useful features of XACML. Your implication that PEP behavior with respect to Obligations is undefined by XACML is simply untrue. Section 2.12 of XACML 3.0 Core (CD06) says: “PEPs that conform to v3.0 of XACML are required to deny access unless they understand and can discharge all of the <Obligations> elements associated with the applicable policy. “
With respect to your email usecase, I would suggest two alternatives. First, it is up to you to define the semantics of your Obligation. It could mean a) that email has been sent and a digitally signed acknowledgement has been received, b) email has been sent, c) email has been queued to be sent or perhaps d) a transactional record of the intent to send the message has been safe stored to replicated storage and a persistent, replicated process will ensure that the message will be sent when a communications channel is available. (Note that in practice there is little difference between b & c. Of course few organizations will select a or d.)
In general, there is no way to truly know that a future event will occur, only that all current steps have been taken to ensure that it will be. Yet, supporting the Obligation: “The data will be destroyed after X days” is an extremely common requirement.
Rather than eliminate Obligations, there have been proposals to allow deployers to better specify the typing and generic semantics of Obligations with respect to other Obligations. There is a draft document in the archives and I am expecting some related work to occur this year in the OpenAz project. Of course, nothing compels an organization to include Obligations or Advice in its policies. You can simply leave them out if you don’t like them.
The second alternative, is to define sending an email as Advice. That means the PEP can allow the access even if the mail system is down. Advice was added to 3.0 precisely to allow the policy to specify actions which are desired, but not required.
I do not understand your global/local dichotomy. Requirements like destroying data for privacy reasons tend to come down from the highest levels of the organization, apply across the board and in some cases are mandated by law or regulation. In any event, I see the ability to use combining algorithms to combine independently authored policies which address concerns at different organizational levels to be a major potential feature of XACML. I am eager to learn about successful or unsuccessful attempts to do this.
Actually, some aspects this debate go back to the days before XACML 1.0. There has always been differences of opinion about how much of PEP behavior should be mandated. Before 2.0 little was required. In 2.0 the need to enforce Obligations and the notion of PEP bias were added, but then there was no way to specify optional behavior or advisory information. Advice was added to 3.0 to fill this gap. Of course the question has never been about how systems should behave, only about how much XACML should specify.
There is more than one way to look at this in theory. One view is that is since XACML is intended to be used in a wide variety of environments, we should only specify behavior which is truly universal and otherwise allow flexibility to meet issues the TC could not possibly anticipate in certain environments.
Another way to look at it is that XACML is a kind of compromise between on the one hand, pure logical languages and on the other Turing-complete languages (which is currently the most popular paradigm, at least for fine-grained access control). The logical languages are easier to analyze because they make a lot of unreasonable assumptions, like that all attributes have consistent semantics and syntax and are available when and where needed and that a consistent semantic model is employed by all applications and systems in the extended organization. Turing-complete languages make it harder to analyze the access control policies, which tend to intertwine application logic and access control logic and general do not reveal the author’s intent with respect to access control.
XACML is a compromise and like all compromises can be ugly in spots. It specifies policies in abstract form, but provides tools for directly manipulating attribute data as needed for evaluation. I agreed that some uses of Obligations are pretty kludgey, but I have sympathy for implementers who have to make a system work in the face of constraints which cannot be changed at least in the short term. I also agree that from a policy analysis point of view it is best to put all of the policy logic in the XACML policies and not distribute it around the environment in Obligation semantics, hierarchical Roles or context handler mappings. These techniques are sometimes necessary, but they limit the ability to use automated analysis tools. I have seen ugly Java code and non-hierarchical XML, but that does not prove that Java and XML are not useful.
I think in the last 10 years we have established that XACML is superior to the commonly deployed standards, such as permission bits, ACLs and RBAC. The current debate encompasses areas where real world experience is quite limited. I believe that we will only be able to evolve XACML usefully if its features are tried to solve real world problems and the results are fed back to the TC along with proposed enhancements. I have always held that it is a mistake to write detailed standards around poorly understood technology. This is one motive for leaving Obligations underspecified.
This brings me to my final point. I invite you or others in your organization to become active in the XACML TC either by email or attending our calls and share your real world experiences and requirements with us so we can make XACML better.