Re: Obligation in rule with example policy

[Polar Humenn <polar@syr.edu>]

Michiharu,

It seems from your proposal that an obligation is added to the set of
obligations for the policy ONLY IF the <Condition> in the <Rule> is True,
regardless of the value of the Effect of the Rule, or the FulFillOn value.
Then from that set of obligations the selection is made from the result of
the combining algorithm.

This says to me, that it is the <condition> that is the important piece.

It may be that a Rule shares a condition, which can easily be done with
a variable reference.

You did not introduce a Rule that has an effect of Deny, yet an Obligation
based on Permit, or visa-versa, which you stated earlier that it still
gets "collected".

If you change your position to Seth's, then I don't buy Seth's argument
that if someone writes that Permit/Deny or Deny/Permit combination, that
the result is meaningless.  Introducing meaningless syntax is not elegant,
and shows a lack of understanding.

Your rules and obligations say the following to me.

Using Deny-overrides:
R1. if access-subject has the registered-user attribute, then Permit.
R2. if access-subject has the suspicious-user attribute, then Permit.
R3. if access-subject has the withdrawal-user attribute, then Deny.

(which is simple, straight forward in calculating the DECISION, and
doesn't involve calculating obligations). Note, that R2 CANNOT be
interpreted as Permit "provided that you notify_admin". This is
extreme clarity.

Then based on conditions and whether the decision is Permit or Deny

O1. if access-subject has the suspicious-user attribute,
    and if decision is Permit, then notify_admin.
O2. if access-subject has the withdrawal-user attribute,
    and if decision is Deny, then add_to_blacklist.
O3. if decision is Permit then charge-$1.

Furthermore, there is no potential to misinterpret or abuse syntax.

Cheers,
-Polar


On Wed, 14 Apr 2004, Michiharu Kudoh wrote:

> messages and heated arguments :-) I noticed there were several
> misunderstandings against my previous email but it may have been caused by
> my misleading description... (I think Seth's interpretation is closer to my
> intention) My intention is that the obligation in Rule should be specified
> with "effect" (Permit or Deny). So again, let me clarify the semantics that
> I want to see. I hope this could sort out the argument among us.
>
> I give an example policy below. Suppose that there is an access control
> policy written for protecting the digital data "music video A". Policy
> rules are:
>
> R1: If the requesting subject is "registered users", then allow access.
> R2: If the requesting subject is "suspicous users" (not registered but
> somehow access comes in), then allow access with obligation of
> notify_to_admin on the requester (for tracing purposes)
> R3: If the requesting subject is "withdrawal users", then deny access.
> P1: If the result of the combining algorithm is "Deny", then add obligation
> "charge $1 to the requester" to the collected obligation from rules where
> "Permit" holds.
>
> 1  <Policy PolicyId="P1" AlgId="ordered-deny-overrides">
> 2    <Target>target resource = "music video A"</Target>
> 3    <Rule RuleId="R1" Effect="Permit">
> 4      <Target>requesting subject = "registered users"</Target>
> 5    </Rule>
> 6    <Rule RuleId="R2" Effect="Permit">
> 7      <Target>requesting subject = "suspicous users"</Target>
> 8      <Obligations>
> 9        <Obligation FulfilOn="Permit" OblgId="notify_to_admin"/>
> 10     </Obligations>
> 11   </Rule>
> 12   <Rule RuleId="R3" Effect="Deny">
> 13     <Target>requesting subject = "withdrawal users"</Target>
> 14     <Obligations>
> 15       <Obligation FulfilOn="Deny" OblgId="add_to_list"/>
> 16     </Obligations>
> 17   </Rule>
> 18   <Obligations>
> 19     <Obligation FulfillOn="Permit" ObligId="charge_$1"/>
> 20   </Obligations>
> 21 </Policy>
>
> - When a requester who is a registered user comes in, Target of R1 becomes
> True and the result the combining algorithm becomes "Permit". Then the
> combining algorithm takes an obligation "charge $1" at line 19 and the
> final result is "access is allowed with obligation charge $1".
>
> - When a requester who is a suspicous users comes in, Target of R2 becomes
> True and the result of the combining alg becomes "Permit with obligation
> notifiy_to_admin" because of line 9. Then the combining algorithm takes an
> obligation "charge $1"at line 19 and the final result is "access is allowed
> with obligation "notify_to_admin and charge $1".
>
> - When a requester who is a withdrawal user comes in, Target of R3 becomes
> True and the result of algo becomes "Deny". Then the combining algorithm
> takes an obligation "add_to_black_list" at line 15 and the final result
> becomes "access is denied with obligation add_to_black_list".
>
> The sentence to which Polar referred below "only if the decision of the
> rule combining algorithm matches the value of the xacml:FulfillOn attribute
> of the obligation in the policy" corresponds to the addition of charge_$1
> obligation in this case.  "... and the corresponding obligations collected
> from the rule(s) being evaluated" corresponds to the addition of
> "notify_to_admin" obligation in "R2". The appropriate obligation can be
> chosen only after the combining algorithm generated the Permit/Deny answer.
> Note that this is what I originally intended and the current specification
> 1.1 is in line with this semantics.
>
> I am afraid but the above intention is probably different from the
> conditional obligation suggested by Polar. In other words, the obligation
> is associated with each rule which is either "Permit" or "Deny" and the
> obligation must be selected only from the rules that matches the result of
> the combining algorithm (line 9). Then some additional obligation specified
> at the bottom of the Policy (line 19) is considered.
>
> Best,
> Michiharu
>
> Polar Humenn <polar@syr.edu> wrote on 2004/04/14 06:46:00:
>
> >
> >
> > Seth,
> >
> > Michiharu's email states:
> >
> > 7.11 Obligations
> >
> > A >>rule<<, policy or policy set may contain one or more obligations.
> >>In
> > the case of the rule, an obligation specified in the rule that is
> > evaluated and "True" evaluation for the rule SHALL be collected per each
> > effect of the rule. When the enclosing policy is evaluated, an obligation
> > specified both in the policy and the collected from the rule(s) SHALL be
> > passed up to the next level of evaluation only if the decision of the
> rule
> >
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > combining algorithm matches the value of the xacml:FulfillOn attribute of
> > ^^^^^^^^^^^^^^^^^^^
> > the obligation in the policy and the corresponding obligations collected
> > from the rule(s) being evaluated.<<
> >
> > Cheers,
> > -Polar
> >
> > To unsubscribe from this mailing list (and be removed from the
> > roster of the OASIS TC), go to http://www.oasis-open.
> > org/apps/org/workgroup/xacml/members/leave_workgroup.php.
> >
>