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] Proposed XACML 1.1 Solution for Item F1:Properties for newcombining algorithms






Hi, Anne and Seth

I think that the difference of views seems to be related to how new
combining algorithms should be defined. My view is anybody should be able
to define new algorithms (if they need). Your view seems to be opposite,
that is nobody can define new algorithm unless it passes the TC approval
process or people can define algorithms as far as they need no additional
property information. However, vendors who needs to define new algorithms
anyhow must plugs-in their specific algorithms to the existing policy
engine. It is the "custom PDP". I think one of the advantage of the current
XACML policy model is to allow each vendor to add plug-in(s) for new
combining algorithm to the existing engine if they think necessary.

>"Properties" has one capability that this solution does not
>provide: it allows an individual policy writer to override other
>policies in the system without having to understand the system as
>a whole.  But a general override mechanism is very insecure: a
>low-level policy writer does not know which other policies it is
>appropriate to override.  It allows a policy writer with limited
>knowledge to override another policy improperly because an
>individual policy writer does not have a view of the entire
>policy hierarchy.

I think that your comment of "a general override mechanism is very
insecure" depends on each application domain. In some cases, it might be
insecure in particular the case of the distributed policy management
environment (you seem to be assuming). But in different domains, for
instance the case where the combining algorithm is used just to combine
finer-grained policies in a centralized policy management environment, it
is no problem. Actually, this is what I originally intended (local policy
writer is allowed to change each policy) and the policy you wrote does not
satisfy the assumption I had.

I also assume that a set of properties that is allowed to specify in the
policy must be uniquely defined per a user specific combining algorithm. It
means that user specific combining algorithm must provide the list of
properties used in its algorithm. Their syntax and the semantics should be
clearly stated as a description associated with the algorithm URI (probably
as a human readable text). Since nobody can see the algorithms in the
future beforehand, it is not possible to list or standardize specific
property (or attribute name) beforehand.

Alternative way might be to have a separate data file that complements the
semantics of the XACML policy (and rule). It does not affect the current
XACML spec.

Michiharu Kudo



                                                                                                                                                    
                      Anne Anderson                                                                                                                 
                      <Anne.Anderson@Su        To:       Michiharu Kudoh/Japan/IBM@IBMJP                                                            
                      n.com>                   cc:       XACML TC <xacml@lists.oasis-open.org>, Seth Proctor <Seth.Proctor@Sun.com>                 
                                               Subject:  Re: [xacml] Proposed XACML 1.1 Solution for Item F1:Properties for new combining           
                      2003/06/11 01:06          algorithms                                                                                          
                      Please respond to                                                                                                             
                      Anne.Anderson                                                                                                                 
                                                                                                                                                    



Dear Michiharu,

We still do not think XACML needs Properties.  The requirements
of the provided use-case can be satisfied using existing
combining algorithms plus an ordered version of an existing
combining algorithm.

Our comments are in-line.

Anne Anderson and Seth Proctor

On 9 May, Michiharu Kudoh writes: Re: [xacml] Proposed XACML 1.1 Solution
for Item F1:Properties for new  combining algorithms
 > > Since any PDP that understands one of these new
 > > combining algorithms that requires parameters will need to be a
 > > custom PDP, why not let this be a custom extension?
 >
 > In your definition, is any PDP that uses custom function(s) a custom
PDP?
 > Is any PDP that uses custom data type(s) a custom PDP? If so, I agree
that
 > any PDP that understands one of these new combining algorithms is a
custom
 > PDP.

Yes, that is Anne's definition.  A "custom" XACML PDP is one that
contains functionality not specified in the XACML 1.0 standard.
XACML has defined standard ways to define extensions to XACML 1.0,
but not standard ways to implement extended functionality.

"Custom" means that one can't buy a vanilla XACML PDP from some
vendor that will handle new combining algorithms, and policies
that specify a new combining algorithm can not be evaluated by a
vanilla XACML PDP.

We still don't see any advantage to standardizing a "Properties"
element.  Policies that use Properties MUST be evaluated by a PDP
that has special code added to implement the special combining
algorithm that uses the Properties.  Since new,
algorithm-specific code has to be added to implement a new
combining algorithm, why not add new code at the same time to
parse policies that contain a custom extension to define some
sort of CombiningAlgorithmParameters element?

[more comments follow below]

 > My observation is that the current XACML schema allows implementers to
 > define new functions with arbitrary arguments while it is not in the
case
 > of new combining algorithms. As Simon suggested in the call yesterday, I
 > think we need a placeholder for a list of attributes for the custom
 > combining algorithm.
 >
 > The following is a use case that you might be interested.
 >
 > - Use case: Privacy protection policy
 >
 > As you may aware, privacy protection policy has a policy structure
similar
 > to the access control policy (it sometimes requires purpose attribute
but I
 > ignore it here). Suppose that each customer specifies a privacy
protection
 > policy for their profile data stored in the merchant server as a XACML
 > policy (including one or more rules) and a site administrator specifies
a
 > policy to combine the customers' policies (as a policy set). The site
 > administrator also specifies privacy protection policies that guarantees
 > the appropriate operation in the company. When the customer writes their
 > policy, they may specify that their policy never be overridden by the
site
 > policy if exists. It is a strong customer policy. When the customer has
no
 > strong preference on his/her policy, it becomes a weak customer policy
and
 > may be overridden by the site policy. This enables the customer's
 > preference (if exists) takes precedence over the site policy.
 >
 > If this is the case, we need to have the place to store "strong" or
"weak"
 > preference parameter of the customer policy. The site administrator uses
a
 > custom policy combining algorithm that checks the significance of
 > customer's policy which generates the decision based on the conflict
 > resolution scheme such as strong policies overrules any weak policies.
The
 > terms of  strong and weak might be different according to the domain,
for
 > example "final" might be used in other domain, or integer values might
be
 > used instead.
 >
 > The following example shows a simple policy. The policy "PS1" and
"P-Site"
 > are site policies and the policy, respectively.  "P1" and "P2" are
 > customer's policy, Alice and Bob, respectively.
 >
 > (The following shows just a rough structure, not the precise one.)
 >
 > <PolicySet PolicyCombiningAlgoId="StrongWeakAlgo" PolicyId="PS1">
 >   <Target>...
 >   <PolicyIdReference>SitePolicy</>
 >   <PolicyIdReference>Policy1</>
 >   <PolicyIdReference>Policy2</>
 > </>
 >
 > <Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="P-Site">
 >   <Property>type:significance, value:weak</>
 >   <Target>...
 >   <Rule Effect="Permit">...
 >   ...
 > </>
 >
 > <Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="P1">
 >   <Property>type:significance, value:strong</>
 >   <Target>...
 >   <Rule Effect="Deny">...
 >   ...
 > </>
 >
 > <Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="P2">
 >   <Property>type:significance, value:weak</>
 >   <Target>...
 >   <Rule Effect="Permit">...
 >   ...
 > </>
 >
 > A custom algorithm "StrongWeakAlgo" reads each policy, refers to the
rule
 > significance argument such as "strong" and "weak", and follows the
conflict
 > resolution described above. If SitePolicy and Policy1 are applicable
 > policies against a certain access request, then the Alice's policy
 > overrules the site policy. If SitePolicy and Policy2 are applicable
 > policies, then some conflict resolution criteria is applied (e.g.
 > deny-overrides).
 >
 > At a first glance, the "StrongWeakAlgo" seems solvable by using ordered
 > versions of permit-overrides and deny-overrides combining algorithms but
 > actually not. It is because that the conflict resolution is based on the
 > policy significance parameter specified by each customer, not on the
order
 > of the PolicyIdReference specified in the "PS1". Using <Property>
element
 > and the custom algorithm, the above problem is easily resolved. Note
that
 > <Property> element is needed even if we standardized the custom
algorithm.
 >
 > For the algorithm, StrongWeakAlgo policy combining algorithm can be
stated
 > as:
 > "In the entire set of policy in the policy set, any policy which has
 > "strong" property overrides any policy which has "weak"property. If the
set
 > of policy has only "strong" policy and they conflicts, then
"Indeterminate"
 > SHALL be returned. If the set of policy has only "weak" policy and they
 > conflicts, then deny policy overrides permit policy."

This use-case requirement can be met by using the proposed
"ordered-deny-overrides" along with the existing
"only-one-applicable" combining algorithms, as follows.

<PolicySet PolicyCombiningAlgId="ordered-deny-overrides"
   PolicyId="PS1">
  <Target>...
  <PolicySetIdReference>Customer1PolicyStrong</>
  <PolicyIdReference>Customer2PolicyWeak</>
  <PolicyIdReference>SitePolicy</>
</>

<PolicySet PolicyCombiningAlgId="only-one-applicable"
   PolicySetId="Customer1PolicyStrong">
  <Target>Customer1</>
  <PolicyIdReference>Customer1Policy</>
  <PolicyIdReference>SitePolicy</>
</>


<Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="SitePolicy">
  <Target>Any</>
  <Rule Effect="Permit">...
  ...
</>

<Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="Customer1Policy">
  <Target>Customer1</>
  <Rule Effect="Deny">...
  ...
</>

<Policy RuleCombiningAlgoId="PermitOverrides"
PolicyId="Customer2PolicyWeak">
  <Target>Customer2</>
  <Rule Effect="Permit">...
  ...
</>

"Properties" has one capability that this solution does not
provide: it allows an individual policy writer to override other
policies in the system without having to understand the system as
a whole.  But a general override mechanism is very insecure: a
low-level policy writer does not know which other policies it is
appropriate to override.  It allows a policy writer with limited
knowledge to override another policy improperly because an
individual policy writer does not have a view of the entire
policy hierarchy.

One final point: although we think combining algorithm properties
should not be added to XACML 1.1, if they are added, we think
they should be simpler than the proposed Properties element.  We
suggest using an xml attribute instead, even though it is not so
flexible.

[no more comments follow]
 >
 > I have no strong opinion on whether or not this algorithm should be
 > standardized because this kind of algorithms often differs from company
to
 > company.
 >
 > Michiharu Kudo
 >
 >
 >

 >                       Anne Anderson

 >                       <Anne.Anderson@Su        To:       Michiharu
Kudoh/Japan/IBM@IBMJP

 >                       n.com>                   cc:       XACML TC
<xacml@lists.oasis-open.org>

 >                                                Subject:  Re: [xacml]
Proposed XACML 1.1 Solution for Item F1:Properties for new combining

 >                       2003/05/08 21:34          algorithms

 >                       Please respond to

 >                       Anne.Anderson

 >

 >
 >
 >
 > I still think this proposal adds a dangerous "catch-all" element
 > to XACML.  Since any PDP that understands one of these new
 > combining algorithms that requires parameters will need to be a
 > custom PDP, why not let this be a custom extension?  Why do we
 > need to standardize it?
 >
 > Before we standardize an element like this, I think we need a
 > strong use case based on actual customer demand.  The use case
 > would need to require that we would standardize one or more
 > combining algorithms that require this element at the same time.
 > As we worked on standardizing such an algorithm, we could better
 > consider whether this <Property> element is really the best
 > solution, or if there is something more controllable that would
 > suffice.
 >
 > Anne
 > --
 > 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
 >
 >
 >
 >
 >
 >

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