[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/Actionelements
All, Personally I think doing multiple requests is a cleaner approach and is much less likely to result in bugs in policies, but I don't see any reason to forbid this if you are willing to handle the resulting complexity in the policies. Perhaps you would want to use some other attribute id than action-id, since it's not really an action id anymore, but a set of actions. Regards, Erik Rich.Levinson wrote: > Hi Craig, Bill, and Erik (and other TC members), > > I have given this some more attention and reviewed some of the > original emails that discussed this issue, for example: > http://lists.oasis-open.org/archives/xacml/200110/msg00107.html > which describes how the xacml tc was originally looking at how > multiple actions are handled in SAML. > > There was some additional commentary explaining different points of > view: http://lists.oasis-open.org/archives/xacml/200110/msg00119.html > > and also a somewhat related item where it was decided that: > ""The XACML syntax should not address the question of which actions > are valid for a particular resource classification."" > http://lists.oasis-open.org/archives/xacml/200203/msg00057.html > > Suffice it to say that I get the point that the intent of the spec is > that a single "action" is what the Request/Action element is intended > to contain. > > That being said, I have also found that this structure has resulted in > a notion that somehow one cannot use XACML 2.0 for such operations as > requesting read and write to a file system. > > It is this issue that I would like to address head-on here. > > It appears to me that "proper" conceptualization of the resources that > are being accessed is important if one wants to use the XACML > Authorization services effectively. > > In the case of file systems, it appears to me that accessing a file > for rwed has been over-simplified conceptually and has been represent > to mean that one is asking to perform 4 simultaneous actions on the > file. Anyone who has written the simplest introductory i/o program > knows that this is not case. > > What one does in practice in some file systems is first request to > "open" the file with "rwed" access privileges granted. Then one > performs individual operations or "r", "w", "e", "d". Presumably, one > can check each of these requests as well. > > Since we've all been working on the Internet so long, maybe it is > easier to present this as if we were developing a web application to > access this file system. How would we do it? > > At least one reasonable approach that comes to mind is the following: > > 1. User goes to www.filesystem.com and is presented with a login prompt > 2. User logs in and is presented with the file system access screen > that contains the following information: > 1. Text box for filename > 2. 4 check boxes labeled r,w,e,d > 3. 1 submit button to request access > 4. 4 grayed out (disabled) buttons labeled R, W, E, D in a column > 5. A text box to the right of the 4 buttons that can be used to > read the file after R is hit, enter text to write to the > file system before W is hit, view the results of exection > when E is hit, or view a confirmation that the file was > deleted when D is hit. > 3. User enters the file name in the text box and checks any number of > the 4 boxes, for example, check, r, w, and d. User hits the submit > button. > 4. Screen is refreshed, and now 3 of the previously grayed out > buttons, R,W,D are enabled and E is still disabled. > 5. User can now go about performing R,W,D operations, one at a time, > each being checked. > > I believe the problem w file system access w xacml is that attempts > have been made to over-simplify the access paradigm and as a result an > impression has been created that it is not a solvable out-of-the-box > problem. > > Using the above task-related approach to file systems, the problem > becomes much easier to solve. I believe it is totally analogous to > requesting access to a workflow. Prior to granting access to workflow > tasks, authorization services generally check to make sure the user > has all the privileges necessary to perform all the steps of the > workflow. > > Similarly, when one requests access to a file, it may analogously be > thought of as a workflow where one might in any random order perform a > discrete read or write or execute, for example, if one was accessing a > program file to examine for a bug, modify with a fix, and execute to > test if the correct result was achieved. > > Therefore, I think it is perfectly legitimate to issue a request for > access to a file system of the following nature: > > <Request> > <Resource> > <Attribute AttributeId="...resource:resource-id"> > <AttributeValue > >file://example/med/record/patient/BartSimpson</AttributeValue> > </Attribute> > </Resource> > <Action> > <Attribute AttributeId="...action:action-id"> > <AttributeValue > >read,write</AttributeValue> > </Attribute> > </Action> > </Request> > > If one wants to then do an actual "read" one would submit the same > Request with action "read". > > How the policies are "written" is not really up to the spec to decide. > However, one way to write the policies is to have the 16 combinations > of the rwed strings individually identified as distinct actions. Among > those 16 actions are also the 4 single actions which can be reused > from the initial task-level access to the individual file operation > requests. > > To me, this is no different than when one loads their card into the > ATM. One is not asking to simultaneously withdraw, deposit, transfer, > check balances, etc. One is simply requesting access to the resource > then individually requesting access to the functions for which they > may or may not be granted permission. > > I think it might make sense for us to put together a guidance document > on how to use XACML for common everyday tasks, since the necessity for > the proper conceptualization of access may not be obvious. > > Comments welcome. (I am also including this message as a word document > because I do not know what to expect the email editors are going to > decide to deliver. :) ) > > Thanks, > Rich > > > > > > Erik Rissanen wrote: >> All, >> >> Sorry for the confusing answer. What I meant is that the standard, as >> far as I recall, doesn't put any restrictions in the content of the >> attributes, so it's not "disallowed", but Craig is right. While the >> standard does not disallow multiple action-ids, the interpretation of >> that is different than what users probably intend. The two different >> action-ids would be treated as synonyms since the <Action> element is >> defined to describe the attributes of a single action. >> >> Multiple action-ids are safe to use if they truly are synonyms. For >> instance, if "pay" and "make_payment" both refer to the same action, >> but different policies have used these two different variants, the >> correct thing to do is to include both in all requests so that all >> policies will work. >> >> However, "write" and "read" are not synonyms and the user probably >> wanted to know whether _both_ read or write are allowed. The result >> will not be what the user expects. >> >> In general there are probably no guarantees about the answer since it >> breaks an invariant in the XACML design: the <Action> element must >> contain attributes of a single action. As Craig says, most likely the >> result will be that the PDP will return a permit if _either_ read or >> write is allowed. This of course depends on the details of the >> policies and other results are possible, but for "simple" policies >> which have been written as if there is only on action-id, this will >> probably be the effect. >> >> In other words: Multiple attribute-ids are allowed by the standard. >> But the standard also says that all the >> <Action>/<Subject>/<Resource>/<Environment> elements contain >> attributes of a single action/subject/resource/environment. So >> including two different action-ids which do not both apply to the >> same action simultaneously is incorrect and will lead to incorrect >> results. >> >> The new Multiple Resource Profile for 3.0 supports multiple actions >> in the form of multiple <Resource Category="...:action"> elements. >> There will be a separate result for each action. >> >> Regards, >> Erik >> >> >> Bill Parducci wrote: >>> Rich, >>> >>> Craig's answer and your response to it indicate to me that while the >>> spec does not prevent this from occurring in a Policy it introduces >>> ambiguity on the Decision. The relationship between Action >>> Attributes is undefined and that is an oversight on our part IMO. I >>> suspect that attempts to rectify this may become cumbersome rather >>> quickly--as they did when we attempted to develop more complex >>> Obligation combinators a while back. >>> >>> I agree that we should discuss text that would dispel any ambiguity >>> in V3. >>> >>> b >>> >>> On Sep 17, 2008, at 4:53 PM, Rich.Levinson wrote: >>> >>>> Hi Craig, >>>> >>>> I would think, in general, that the Request is intended to be for >>>> "read" AND "write", although I do not believe that it is necessary >>>> to imply this, since the xacml spec does not address it directly, >>>> afaik. However, from a purely logistical plain language point of >>>> view, I would assume that this was a Request for a Decision to >>>> allow the subject to read and/or write to the resource. >>>> >>>> All XACML does is answer the question, it does not in general, know >>>> "how" the subject is going to use the results of the Decision, so >>>> I would assume a conservative Policy would look at the "worst" case >>>> scenario and be designed to process that worst case and give >>>> maximum protection. i.e. the Policy should assume the Subject will >>>> use the Decision to do anything possible based on the contents of >>>> the Request. >>>> >>>> Some systems might be designed so that every Request is a one shot >>>> deal where the Subject makes the Request, uses it once, then if the >>>> Subject wants to use the Resource again, then the Subject would >>>> have to make another Request. Other systems might take more of a >>>> "session" perspective and allow the Subject to use the Decision for >>>> any number of actions while the presumably "application-controlled >>>> session" is still in progress. >>>> >>>> My understanding is that XACML was designed to be as flexible as >>>> possible, and so I do not believe either interpretation in prev >>>> paragraph is the "correct" one. I think either is equally as good. >>>> >>>> But, in any event, the reason for my original question is that it >>>> was suggested to me that multiple <Attribute >>>> AttributeId="...action:action-id"> elements were not allowed in >>>> XACML. That did not sound correct to me technically, based on what >>>> I said in the original email, and if I then take the assumption >>>> that technically it is allowed, I find nothing particularly wrong >>>> with it from a common sense Policy design perspective either. >>>> >>>> I do want, however, to unambiguously say that it is allowed, so >>>> that the people who asked me about it can feel comfortable moving >>>> ahead doing design on that basis. So, if there is any restriction >>>> somewhere that is normative in nature or would cause anyone to say >>>> it is not allowed it would be useful to know. I may even suggest >>>> some text to add to the spec to remove any possible ambiguity in >>>> this matter. For example, in section 6.3 there is text that to me >>>> unambiguously indicates that resource-id can have multiple values >>>> in a single Request. Also in the RSA Interop, the HL7 permission-id >>>> attribute had multiple instances. I am sure each of these has their >>>> own justification, however, the point is that there is no >>>> justification to dis-allow any of this behavior, which is the >>>> definitive result I am looking to get at here. >>>> >>>> Thanks, >>>> Rich >>>> >>>> >>>> >>>> Craig Forster wrote: >>>>> Hi all, >>>>> >>>>> I don't think it's disallowed explicitly, but writing policy to >>>>> handle it >>>>> well would be difficult. >>>>> >>>>> For example, say the policy has Permit for "read" but no policy >>>>> allowing >>>>> "write" (but not Deny either). The request, IMO, is asking "can I >>>>> read AND >>>>> write this resource?". Should the request be permitted? The >>>>> policy would >>>>> return Permit, even though it really should return NotApplicable. >>>>> >>>>> The provisions to handle multiple Resources as separate requests >>>>> are for >>>>> this type of scenario. >>>>> >>>>> Thoughts? >>>>> >>>>> Regards, >>>>> Craig >>>>> >>>>> --- >>>>> craig forster | staff software engineer >>>>> ibm australia development labs >>>>> >>>>> >>>>> >>>>> >>>>> From: Erik Rissanen >>>>> <erik@axiomatics.com> >>>>> To: "Rich.Levinson" >>>>> <rich.levinson@oracle.com> >>>>> Cc: xacml >>>>> <xacml@lists.oasis-open.org> >>>>> Date: 18/09/2008 >>>>> 03:19 >>>>> Subject: Re: [xacml] Question on xacml 2.0 - multiple action-id >>>>> Request/Action elements >>>>> >>>>> >>>>> >>>>> >>>>> I don't recall anything in the standard which disallows it. Anyone >>>>> else? >>>>> >>>>> And I don't see any reason for disallowing it either. >>>>> >>>>> /Erik >>>>> >>>>> Rich.Levinson wrote: >>>>> >>>>>> I have been asked whether a Request/Action element can >>>>>> contain more than one <Attribute AttributeId="...action:action-id"> >>>>>> element: >>>>>> >>>>>> For example, what would be wrong with Example 4.1.2 having >>>>>> the following: >>>>>> >>>>>> <Action> >>>>>> <Attribute >>>>>> AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" >>>>>> DataType="http://www.w3.org/2001/XMLSchema#string";> >>>>>> <AttributeValue>read</AttributeValue> >>>>>> <AttributeValue>write</AttributeValue> >>>>>> </Attribute> >>>>>> </Action> >>>>>> >>>>>> Apparently, some have the opinion this is not >>>>>> allowed. I think that opinion is mistaken, because I have not found >>>>>> any reason that this is disallowed. Is there anything that forces >>>>>> us to only have one value for action-id? >>>>>> >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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]