[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. Hal From: Nick Duan [mailto:nduan@verizon.net] Indeed, the PDP has no way to ensure/enforce what PEP is doing on obligations & advices. It seems that how a PEP behaves is really in the hands of implementers, not determined by the spec. In that case, shouldn’t the TC consider removing obligation/advice elements from the spec so you can have a more semantically sound spec? We had some problems when dealing with the obligation on the PEP part in the past. For instance, if an obligation requires sending an email out when a PEP performs a “Permit”, but the email server is down, despite the fact that email function is non-essential, but you will have to deny access according to the spec. Furthermore, to add to the semantic confusion, you can define an obligation in such a way (or nothing prevent people from doing so) that it is actually perform the real Permit or Deny function in a PEP. It seems that the obligation/advice elements really deal with business logic/rules that are not access control related. The initial idea of XACML is to create a centralized access control policy, but what obligation/advice are dealing with are really local matters. Mixing central policies with local matters will cause confusions. Nick From: Hal Lockhart [mailto:hal.lockhart@oracle.com] You have to realize that there is a distinction between the decision produced by a PDP and the action taken by a PEP. XACML defines precisely the conditions for all possible decisions of a PDP. XACML only defines some of the required behavior of a PEP. A few examples: When a PDP says “Not applicable” some PDPs will deny access, some will consult a different PDP. When a PDP says “Indeterminate, missing attributes” some PDPs will locate additional attributes, some will deny access. When a PEP asks for a hypothetical (what if) decision in order to analyze or debug policies, the PEP will take no enforcement action whatever, since there is no actual request to permit or deny. (Note that this does not violate the text you cite below.) In the case you mention the PDP decision is “Permit” with Obligations. That ends the involvement of the PDP. However XACML specifies that in such a case, if the PEP is unable to understand and comply with the Obligation, it MUST NOT permit access. You could say that in this case, the PEP acts as if the PDP decision had been DENY. However, the actual PDP decision is still Permit with Obligations. If fact, the PDP has no way of knowing the PEP was unable to comply with the Obligations. Hal From: Andrea Margheri [mailto:margheri.andrea@gmail.com] Hi, I’m a student of University of Florence and I’m doing a master thesis on XACML 3.0 and the use of obligations. I’m trying to define a formal semantic for XACML 3.0 and I don’t understand how Obligations are managed by the PEP with Base algorithm. In fact in section 7.2.1 the standard says: “PEP shall permit access only if it understands and it can and will discharge those obligations” but it doesn’t say which is the decision of PEP when it can’t understand the obligations, is it deny or indeterminate? And for a PDP authorization decision “Deny” with unsuccessful obligation, it becomes indeterminate? Thanks Andrea |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]