[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Environment description in target
I think it might be reasonable to index your policies according to the time of day to which they apply. For example, Request A is made at 9:30pm, so start by looking at all policies that apply to times between 9-10pm. So, while I don't have a specific requirement for this, I think it is a reasonable extension, especially since it just allows environment to be treated the same way we treat subject, resource, and action. Actually, I think indexing on time of day is more likely than indexing on a particular action! Anne On 23 April, Michiharu Kudoh writes: Re: [xacml] Environment description in target > From: "Michiharu Kudoh" <KUDO@jp.ibm.com> > To: Polar Humenn <polar@syr.edu> > Subject: Re: [xacml] Environment description in target > Date: Wed, 23 Apr 2003 13:40:41 +0900 > > > >Now, we want to add environment. Which was one of the things we thought > >too variable to index, such as access time. > > I am not saying that every expression for environment should go into the > target section. I am just saying that if an environmental value is > indexable as with subjects, resource, and action, then it would be > reasonable to make a space for describing it in the target section from > performance viewpoint. If this is the case, the implementation can choose > applicable XACML policy by using four axes, subject, resource, action, and > an extra indexable parameter (depending on the application). If the > environment variable is not indexable (e.g. access time etc.), it should go > into the Condition element that allows more generic expression. This > extension is still in line with our design philosophy that the target > should be as simple as possible as far as I understand. Moreover, > implementations will not have to write a large amount of new code to > support this functionality by subclassing implemented for the current > target class. > > >I think Micharu's "purpose", which seems more like a "role-based" > >approach", may be taken care of by adding a "purpose" attribute to the > ><Action> element. Could it not? > > As far as I understand, "purpose" in usual privacy protection policy is > neither action nor subject, but an independent argument. In most cases, > purpose is indexable just like subject and action. For example, "order > fulfilment", "marketing" and "Web site development" are frequently used > purposes. An example privacy policy is "If the requesting subject is > operator, resource is order information, action is read, and purpose is > order fulfillment, then access is allowed". If there are thousands of such > policies, policy should be indexed using subject, resource, action, and > purpose and it improves the performance of selecting the applicable policy > from the policy storage. > > Michiharu Kudo > > > > Polar Humenn > <polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP > cc: XACML TC <xacml@lists.oasis-open.org> > 2003/04/22 22:51 Subject: Re: [xacml] Draft proposal for new work item: properties for new combining algorithm > > > > > > > > I thought we decided against these two approaches a while back. > > With the current approach there can be no typechecking or correctness of > the combining algorithm, unless we come up with a type/parameter scheme > for the combining algorithm at the point of its application. > > We also need to maintain implementation extensibility. This would also > require a parameter type definition into the combining algorithm > application, such that generic engines may deploy such combining > alogorithms in a generic fashion. (i.e. the engine must know the > position/correlation/type of the formal parameters in conjunction with the > actual parameters. > > Also, another snag, I have heard mumblings about to references to rules, > another thing we decided against. > > The rule property approach severely complicates matters, as a > compiler/checker needs to chase down the rule to find out what the types > of its properties are. Also, once you start referencing rules outside the > rule combination, those properties are in a sense, can end up meaningless > with respect to each other. Forexample, take Michiharu's priority > example. If I am writing rules that are statically combined, then the > priority makes sense in relation to the other rules. In the reference > case, you have no such control. I can always change the priority to > 9999999999, if I want. Also, the rule may be written without any knowledge > of the combining algorithm in which it will be a constituent. > > The next proposal at the bottom states that Environment should be come > part of the target. I thought we had arguments against that as well, > based on efficiency and indexing resources (java, unfortunately added > subjects to complicate matters). > > Now, we want to add environment. Which was one of the things we thought > too variable to index, such as access time. > > It seems that people want to use the target as successive conditions in an > evaluation. Since that is the formal semantics behind that structure, it > seems, at the very outset, to be plausible. However, the target was meant > to be used for indexing policies/rules for quick recovery. > > I think Micharu's "purpose", which seems more like a "role-based" > approach", may be taken care of by adding a "purpose" attribute to the > <Action> element. Could it not? > > Cheers, > -Polar > > > > On Tue, 22 Apr 2003, Michiharu Kudoh wrote: > > > This is a draft proposal for a new work item regarding "properties for > new > > combining algorithms". XACML's extensibility allows local vendors to > write > > new combining algorithms. > > It is often the case that such algorithm uses algorithm-specific > parameters > > (e.g. rule priority number). But the current schema definition has no > space > > to specify such application specific parameters (or a too restricted > > schema) > > > > - Simple extension to support parameters for new combining algorithms > > > > There are several ways to support arbitrary parameters in the policy. > > > > 1) Add priority attribute in the Rule element > > 2) Add priority element below the Rule element > > 3) Allow to insert any element below the Rule element > > 4) Add a certain element (e.g. <Property> element) for a placeholder that > > allows any element below it. > > > > The first two items are not appropriate since it is not applicable to the > > cases where another parameter is needed (e.g. fuzzy parameter). > > The third might be good but it may conflict to the pre-defined elements. > > The fourth is more generic and better than the above. A sample example > is: > > > > <Policy> > > <Rule> > > <Property> > > <Priority>1</Priority> > > </Property> > > <Target> > > <Condition> > > </Rule> > > <Rule> > > <Property> > > <Priority>2</Priority> > > </Property> > > <Target> > > <Condition> > > </Rule> > > </Policy> > > > > I use <Property> element above which allows any element/attribute below > it. > > Next, there are several possibilities for the place where the <Property> > > element can be put. > > > > 1) Several elements can have <Property> but not all. (e.g. only > PolicySet, > > Policy, and Rule elements can have <Property>) > > 2) Any elements can have <Property> > > > > If we choose the first, the problem would be which elements are allowed > to > > have <Property>. > > If we choose the second, there is no problem about the extensibility. > > > > Once we come to agreement on the above issues, the next issue is how we > > modify the schema definitions. I don't discuss further in this proposal. > > > > > > - Another extension: support environment in target element > > > > The current policy model allows policy writers to specify policy on > targets > > of subject, resource, and action but not on environment. The conclusion > of > > the TC about not specifying the environment in the target was that 1) > usual > > access control policy consists of a access triple, that are subject, > > resource, and action, 2) environment variables such as current time do > not > > fit the limitations set on the target element. > > > > Setting aside the first item, some application will benefit if XACML > > supports environment in the target. For example, privacy protection > policy > > often consists of four arguments, that are subject, resource, action and > > purpose. In most cases, purposes used in a certain policy are on list and > > they are described in the policy as equality checking (e.g. if subject is > > Operator and purpose is order fulfillment, then permit the access). Its > > meaning is much closer to subject, resource, and action in the target > > rather than arithmetic computation using the current time and date time. > > One idea is to support purpose (or any attribute that policy writer wants > > to specify) that can be used by a vender specific rule combining > algorithm. > > A sample privacy protection policy would be: > > > > <Policy RuleCombiningAlgId="DenyOverridesWithPurpose"> > > <Rule> > > <Target> > > <Subjects> > > <Subject>... subject is operator </Subject> > > </Subjects> > > <Resources> > > <Resource>... resource is /order </Resource> > > </Resources> > > <Actions> > > <Action> ... action is read </Action> > > </Actions> > > <Environments> > > <Environment> ... purpose is fulfillment </Environment> > > </Environments> > > </Target> > > </Rule> > > </Policy> > > > > Therefore, my proposal is to allow <Environments> element and > > <EnvironmentMatch> element in the <Target> element. > > > > Michiharu Kudo > > > > > > > > > > -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]