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


Yes, by using the multiple resource profile you can package one request 
which asks about multiple resources. In xacml 2.0 you cannot ask for 
multiple actions. In XACML 3.0 you can.

Regards,
Erik

Prateek Mishra wrote:
> 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]