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] Draft proposal for new work item: properties for newcombining 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
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]