[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 new combiningalgorithm
>Must *all* rules carry a set of properties?
No. A set of properties described in each rule depends on the semantics of
the user-defined combining algorithm. If that algorithm requires three
properties, then all the rules enclosed in that algorithm (policy) must
provide three properties. If the algorithm is XACML standard one, then no
properties should be specified.
>Must all rules carry property values consistent in type and
>position with all other rules?
If you are referring to rules in a certain policy with some user-defined
combining algorithm (that requires some properties), then the answer is
yes. The scope of the required property is per combining algorithm.
>Must the same condition hold for the semantic value of those values
>across all rules?
As I wrote above, property is per algorithm thing.
>What would the rule combining algorithm do if there are "missing" or
>"extra" properties?
While it depends on user-defined algorithm, it might be good to give some
guidelines such as the algorithm should return "indeterminate" if some
attributes are missing or extra properties are specified.
>Are we going to have Rule references?
No.
Michiharu Kudo
Polar Humenn
<polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP
cc: XACML TC <xacml@lists.oasis-open.org>
2003/04/23 23:05 Subject: Re: [xacml] Draft proposal for new work item: properties for new combining
algorithm
Hi Michiharu,
I'm more concerned about the more formal semantic aspects than the syntax.
Must *all* rules carry a set of properties?
Must all rules carry property values consistent in type and position with
all other rules?
Must the same condition hold for the semantic value of those values
across all rules?
What would the rule combining algorithm do if there are "missing" or
"extra" properties?
Are we going to have Rule references?
If so, what ramifications do the properties bring to bare in the face of
developing rules in isolation to each other, such as "priority".
A simple syntax proposal does not suffice.
Sure, we can stick a whole bunch of syntactical stuff into rules,
policies, and policy sets, (all of which I think there is too much
already). However, the more variable unweildy parts you stick in, the more
unstable the whole becomes. The next thing you have to do is write a
"Profile" document for the use of XACML for each specific purpose. Uggg.
This is the exact fiasco the X standards run into, X.500 (i.e. LDAP
Profile, and profiles for the profile), X.509 (PKIX Profile(s)). Although,
I guess, that approach keeps some people actively employeed.
I'm not saying it cannot be done, we just have to think about it
thoroughly.
For instance, if we allow properties to rules, and have rule references,
we should then allow (more like somebody would want) properties added to
policies and policy sets? Then why even bother with rules? They are the
same as policies, etc.
However, requirements are requirements. We ended up "targeting" rules,
which I still think was a mistake, because it made it too much like
policies and increased the administration costs, but it somehow turned
itself into a requirement, and there we have it.
Okay, I'll get off my soapbox now, and go hide in the corner. :)
Cheers,
-Polar
On Wed, 23 Apr 2003, Michiharu Kudoh wrote:
>
> Hi, Polar
>
> I understand your concern on the typechecking of the algorithm.
> So what if the property is described as follows?
>
> <Policy RuleCombiningAlgId="myAlgoOfPriority">
> <Rule>
> <Property>
> <Attribute AttributeId=".. priority" DataType="..Integer">
> <AttributeValue>1</AttributeValue>
> </Attribute>
> </Property>
> <Target>...
> <Condition>...
> </Rule>
> </Policy>
>
> This proposal is not related to rule reference extension, so please don't
> confuse.
> For the environment, I respond in separate message.
>
> 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
> >
> >
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]