[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
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.
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:email@example.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:I can try to give my perspective from a slightly different angle... IMO the need for a slash, dash or comma to enumerate attributes within a framework that has been explicitly constructed to provide to clarity and interoperability is philosophically wrong. I don't not think there should be a need for such things because compound attributes as suggested here should not exist. We cannot prevent it from happening but we can discourage it and I think we should. Beyond the points Erik and Craig raised I believe this because I don't think this is just a system related issue. Lacking any form of referenceable standard for this notation means it will become highly localized and therefore more likely to mutate/be misunderstood over time by policy editors interacting with the system. We can of course create our own attribute combiner notation to define what ", + /" means, but I suggest we not :) The attribute "readwrite" works so long as it refers to a distinct action, not as implied notation equivalent to: "parse out the english words that are analogous to filesystem actions and then treat them as distinct entities once parsed." Not sure if this makes it any clearer. :-D b On Sep 18, 2008, at 12:38 PM, Rich.Levinson wrote:Hi Bill, et al, I am not sure I am following the argument. If I removed the comma or replaced it with a slash or dash would that address the concern? Basically, I am saying in the simplest case, let's take simply file read and write that there are 3 possible "services" that can be offered (possibly a different rate is charged for each): * readwrite * read * write As described in previous email, each time a new file is selected, the user picks the desired service level and hits submit. The policy determines if the user has been granted access to that file at that level of service. If so, then the user is presented with the appropriate form for using the service, which only has 2 operations: read and/or write. Each time the user requests one of the operations the policy determines if they have that access (and they are charged a usage fee). There are no compound operations. It is simply specify the service you want, then if you get it, use the service. The fact is that a file is a more complicated resource than just the number, n, of possible discrete "runtime" operations you can perform it. When a real file system is used each file has potentially n**2 - 1 "modes" in which it can be initialized prior to providing "runtime" access. The problem I have seen using XACML is that attempts have been made to provide access to these actual n**2-1+n discrete operations (or actions) using only n actions. I believe my proposal is simply addressing the reality of the problem by enabling the ability to express the options that are physically available, and doing this in a manner where a user specifies the exact action they are going to use at the time they are about to use it and nothing more. Comments? Thanks, Rich Bill Parducci wrote:Rich, I think that it does introduce complexity in that once compound actions are introduced the relationship between them is ambiguous unless further machinery/description is also introduced to handle it. The comma used in "read,write" lacks referenceable meaning in the current specification and therefore lends itself to open interpretation. In general we have always tried to avoid this type of situation because it tends to lessen the chances for interoperability. Therefore I would offer that is not just a complexity/performance issue. One could argue that the TC doesn't dictate attribute values, however it seems to me that there is merit in discouraging the creation of non-normative syntax for creating compound attribute values, particularly since there seems to be a viable alternative at hand that provides the desired functionality. b On Sep 18, 2008, at 10:31 AM, Rich.Levinson wrote:Hi Erik, I agree there are multiple ways to address the problem. Personally, I do not believe the approach I have suggested necessarily results in any significantly increased complexity. However, I do not think that can be the basis for how the TC presents its recommendations and guidelines. For example, the fact that the whole policy structure and requests and responses are written in the spec in xml does not constrain the implementor to use xml at all, as I understand it. It is very possible that different implementation technologies lend themselves to more or less efficient policy processing depending on how one writes the policies. Just because an XML representation of a Policy is complex doesn't mean that the underlying implementation of that Policy necessarily has to be complex. Thanks, Rich--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]