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: Obligation in rule with example policy






Hi, Polar and Seth

I could not follow all email exchanges between you two because of too many
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.
>



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