[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/Action elements
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]