[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Question on xacml 2.0 - multiple action-id Request/Action elements
|
Hi Hal, Thanks for your thoughtful reply and thanks also to Erik, Craig, and Bill. However, I am still not satisfied that I have communicated my point effectively, either that or I am still missing something essential from the discussion. Let me first say that I think have thought thru most of the suggestions that have been offered at least for an initial understanding. I have read the hierarchical and multiple resource specs and confess that while I can sort of follow much of the text in those specs, I feel that I am missing context as to what problems they are solving and as a result find them very difficult to grasp. However, I have not given up and intend to pursue them further, and expect I will have to create my own examples as straw men and see if I can apply the specs to solve those examples. That being said, let me return to this particular discussion. Again, I am not pursuing this for the sake of discussion only, I have been explicitly asked about the file system situation, and I believe it has raised an important "issue", because I believe that depending on how one "looks at" this problem one can legitimately come to different conclusions on how it can or should be approached. I think Hal's reply has characterized the situation very well, and I agree with most if not all of what is there, starting from the initial notion that the "policy author and the PEP must have the same notion about the semantics of Actions and Resources". Also, I think Hal's statement about defining an action like "readwrite" is also exactly the point I am trying to get at and generalize a bit in order to describe what I think might be considered a "design pattern" for policy definition which is useful for addressing a certain class of problems. This is not to say it is the "only" way to address these problems, but potentially "a useful" and consistent with the philosophy of XACML way to address these problems. In this "one more stab at this", let's back away from the file system for a moment and consider the general problem of protecting "workflows" or "tasks", which are generally considered to be some kind of semi-structured sequence of operations that must be performed either in some specific order or any order in order to complete the workflow or task. (Let's stick with the term "task" since it is short and we will use it to mean the "whole job", the "whole business process", but also think of it as being assigned or selected to only a single person.) For example, a person wants to do a particular task, which requires the person to be able to perform individual operations a, b, and c, each of which are individually protected operations. In general, in systems like this, for efficiency purposes, managers generally do not want persons to start tasks, get part way thru, and then find they don't have the permissions necessary to complete the task. Let's say a particular instance of an example task requires
A common way this situation can be overcome is to initially have the person indicate their "intent" to do this task, then their privileges are checked, and if they have a,b,c then they are allowed to proceed. Then each subsequent individual operation a or b or c is checked as the task proceeds. The simple way to implement this is to define an operation: "StartExampleTask" and so the request would come in for action StartExampleTask and the policy would check for a,b, and c and if all 3 were satisfied the user would be granted a Permit and allowed to continue. If not the request would be denied. So, I would consider this to be a "task-oriented policy design pattern" that could be used to handle task-oriented situations. It could probably go in a manual with many other policy design patterns. The pattern might be defined as: for multi-operation tasksIf there is agreement that this kind of a policy design pattern is reasonable for xacml, then I think it is reasonable as well to apply it to file systems. i.e. define actions, such as openFileForReadAndWrite, which actually do exist in some but not all file systems, then check for each subsequent read and write if necessary - some probably will, some may not (only one action is checked for any request, the first action in both the task and file examples could be considered a "contrived" workaround or it could be considered simply a reasonable way to address this kind of a problem). I think that if conceptually there is agreement that this kind of application and associate policy is reasonable then the semantics and syntax of the action names really are just an implementation detail, where some may see opportunities for shortcuts etc, but nothing is explicitly required or forbidden. In summary, my sense is that I should be able to tell people that this kind of approach might work for their situation without having much of the "XACML community" view it as some kind of undesirable practice. The reason I am even bringing it up is because I have been asked, and the suggestions seem to me to generally be in the "wait for 3.0" or "extend xacml w new constructs" domain rather than "XACML 2.0 can do that in a reasonable way" domain. So, the point of these emails from my perspective has been to raise awareness of this issue (at least, what I consider to be an issue) and find out what people think, and hopefully to get enough buy-in to be able to consider at least the task oriented pattern to be legitimate, then people can apply it whereever they think appropriate. Thanks, Rich First off, let me say what I think the "bigger" issue is, from my perspective Hal Lockhart wrote: 20080919103239521.00000001464@hlockhar02" type="cite">Rich, I am having a lot of trouble figuring out what this debate is about. The philosophy of XACML is that the policy author and the PEP must have the same notion about the semantics of Actions and Resources. The entities named in policies must correspond to the enforcement done. The Resource and Action should be the actual resource and action requested by the untrusted party. However the PDP knows nothing about this. It simply performs well defined operations on the available data to calculate a result. If the PEP knows that a user is going to read and write and wants to find out before the read if the write is going to be allowed, then it can ask for a decision on read and on write. If efficiency is an issue, then this can be done in a single request which will produce a decision for each alternative. (I thought we made this legal in 2.0, but apparently it is at least legal in 3.0.) If the application logic is such that a user wants to do something which involves either doing foo or bar to Resource X, the PEP can ask for decisions on foo and bar and do whichever one is allowed (or pick one if both are allowed.) If the policy author wants the rules for reading and writing to be different from the combination of rules for reading and the rules for writing, then she can create a policy with an action like "readwrite" as already noted. In a file system which uses permission bits, there is a special efficiency to retrieving multiple permission bits, since it costs no more (or perhaps even less) to get several permission bits than to get one permission bit. In XACML there is no such economy and in fact the decision for read and for write may involve completely disjoint policies. I think the model underlying the UNIX file system permissions is flawed in that it breaks encapsulation and presumes a particular implementation. For example, to create a file you need to be able to write the directory and write the file. I think that enforcement and the attributes referenced in policies should reference the actual requests available to users (programs) of the system. If "create a file" is an atomic operation, then that should be an action, not the underlying primitive operations performed by the OS which might involve reading and writing various data structures invisible to the application. If you are saying we should be writing more "how-to" documents on XACML, I completely agree. A useful task would be for somebody to scan the xacml-users list and put the interesting questions and answers in the developers guide. I can offer a comment on the history of deciding not to enforce enumerated Actions on resources by defining Resource types. We had already decided to implement data types and do strict typing on all operators and functions. (A majority, but not initially a unanimous decision.) I think the general feeling was that a second type system would just make things too complex and not add enough value to be useful. Keep in mind that the core spec only addresses the expression and runtime evaluation of policies. Just because the PDP does not enforce enumerated actions per resource type does not mean that policy authoring tools cannot. I believe a good policy editor can and should be aware of legal actions on a resource type and restrict policies at the time they are created, assuming the information is available to it. Finally note that the "name" of the Action is not the only possible action attribute. For example, I have argued that the contents of an application request message or the input values to a function or subroutine should be encoded in the request contest as Action Attributes. Or consider the following use case. In some organization, any Delete action on some class of resources is considered a "dangerous" action and requires approval of an Officer of the Company. Conceivably I could construct a policy referencing the "dangerous" attribute and at runtime the context handler would fetch the attribute value from some repository of action/recource pairs. In short other than the call for more descriptive documentation, which I agree with, I don't see what the TC is supposed to do here. Hal-----Original Message----- From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Friday, September 19, 2008 3:48 AM To: Bill Parducci Cc: Rich.Levinson; Craig Forster; xacml Subject: Re: [xacml] Question on xacml 2.0 - multiple action-id Request/Action elements> All, Rich, I agree with Bill. It's a bad idea to model XACML policies in that manner, but if you like that approach, then that is good for you. You know what the XACML functions and elements do, so if you can make "compound actions" work, then that's fine. XACML has been designed with the assumption that the actions are not compound actions, but I don't think the standard should be interpreted to make normative "philosophical statements". The spec says how the bits and bytes are processed into a result. That's it. How you use it, is up to you. Rich, you were asking that "the TC presents its recommendations and guidelines". My personal recommendation and guideline is: don't do it like that since it will lead to complex policies. Use the multiple resource profile instead. I don't know about the rest of the TC. Best regards, Erik Bill Parducci wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]