[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
Isnt the general issue here "box-carring" - I have a whole set of Az requests but I would like to combine them in a single message. Isn't the question of whether multiple actions are permitted in a single request in XACML 2.0 a lower-level technical issue? So I guess my question is: if I want to ask a set of questions, can I somehow package them in a single request message in XACML 2.0? - prateek > 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 > > > --------------------------------------------------------------------- > 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]