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