RE: [xacml] Question on xacml 2.0 - multiple action-idRequest/Action elements

["Hal Lockhart" <hal.lockhart@oracle.com>]

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