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


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.


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]