OASIS eXtensible Access Control Markup Language (XACML) TC

RE: [xacml] [glossary] Comments

  • 1.  RE: [xacml] [glossary] Comments

    Posted 10-29-2001 07:14
    
    I just wanted to describe two different scenarios, not one scenario that
    uses
    two different interpretations for one conditional statement. In other
    words,
    a system in some company may use a condition statement as a precondition.
    In that system, the PDP always returns a binary answer according to the
    result of the condition evaluation. On the other hand, another PDP in
    different
    company may use a condition statement as a postcondition like "if all the
    conditions are met, one of the required actions is to enforce the
    following."
    I think this flexibility allows wider applicability of XACML policies.
    
    regards,
    Michiharu Kudo
    
    
    From: Hal Lockhart <hal.lockhart@entegrity.com> on 2001/10/26 22:23
    
    Please respond to Hal Lockhart <hal.lockhart@entegrity.com>
    
    To:   Michiharu Kudoh/Japan/IBM@IBMJP, "Tim Moses <tim.moses"
    cc:   xacml@lists.oasis-open.org
    Subject:  RE: [xacml] [glossary] Comments
    
    
    
    I don't see any reason why the same attribute can sometimes be a
    precondition and sometimes a post condition. I do think the distinction
    between a precondition, that a PDP can satisfy itself is already true and a
    postcondition, that the PDP must ask the PEP to enforce is a useful one.
    
    I hope you are not proposing that we have a policy language that can say
    "try to determine if this condition is true, but if you can't, ask the PEP
    to try to enforce it."
    
    I would much prefer a language that can clearly say "don't allow the
    actions
    unless this is true" and also say "if all the conditions are met, one of
    the
    required actions is to enforce the following."
    
    Hal
    
    > 1. Policy Condition
    >
    > XACML's definition is similar to SAML's definition. It is close to
    > the notion of post-conditions as suggested by Carlisle's requirement
    > draft, item 16.
    > http://lists.oasis-open.org/archives/xacml/200109/msg00100.html
    >
    > This is also close to the notion of PolicyAction defined in the Policy
    > Core Information Model (RFC3060)
    > http://www.ietf.org/rfc/rfc3060.txt
    >
    > On the other hand, I think we have to define a term for the condition
    > that is associated with each access control rule stored in the PRP.
    > That condition is evaluated in selecting access control rules
    > in response
    > to each decision request. It is close to the notion of
    > pre-conditions or
    > PCIM's PolicyCondition.
    >
    > But I think pre-conditions and post-conditions are not necessarily
    > separate.
    > Suppose that there is a rule saying "Access is allowed if Initiator is
    > older than 18." If the decision request contains a birthday
    > attribute of
    > the Initiator, then the above rule potentially means grant.
    > The statement "if Initiator is older than 18" associated with
    > that rule
    > is pre-condition of the rule. In this case there is no need for
    > post-condition
    > in the authorization decision.
    >
    > But, it may be the case that birthday attribute is not
    > available in PDP
    > side. Then PDP may make a decision such as "access is allowed, if
    > Initiator is older than 18." In this case, we can call the additional
    > condition as post-condition or Policy Condition.
    >
    > We should use two different terms in each case described above.
    > My suggestion is the following:
    >
    > pre condition: Rule Condition
    > post condition: Policy Condition