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] 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
  1. 1000 a operations
  2. followed by 1000 b operations
  3. followed by one c operation.
If this person is allowed to do steps 1 and 2 then they find they can't do step 3 then they will have wasted a lot of time and accomplished nothing of value because the task cannot be completed.

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 tasks
  • IF ( (the task requires more than one specific operation to be performed)
  • AND (the task sometimes requires all operations to be executed at least once in order to complete) )
  • THEN (define an initial operation which requires the user to be authorized for ALL the operations that can be performed within the task BEFORE the user is allowed to start the task)
If 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">

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.


-----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,

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


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.



Bill Parducci wrote:

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

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.


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.

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:
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:



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