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] | [Elist Home]


Subject: RE: [xacml] [glossary] Comments



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





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


Powered by eList eXpress LLC