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/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]