RE: [xacml] What are we arguing about?

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] What are we arguing about?

Michiharu - I am working on v0.8 of our draft document.  Simon has asked that I include sample policy instances in it.  So, perhaps I can base them on the examples you provide below.

Briefly, the way around the problem you cite is to nest an "or" inside a "not", like this ...

<and>
        <role = internalUser>
        <not>
                <or>
                        time=weekend
                        value greater than $1,000
                </or>
        </not>
</and>

I'll be a bit more rigorous in my sample policy instances.

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Michiharu Kudoh [mailto:KUDO@jp.ibm.com]
Sent: Thursday, December 20, 2001 7:14 AM
To: Tim Moses <tim.moses
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] What are we arguing about?

Hi, Tim

Your policy specification becomes much closer to what I intended. I think
that the readability was greatly improved !
But I have several comments to your description regarding the grant and
deny issue.

According to your policy, the externalUser cannot read any portion of the
document. In the second policy, it only
says that "if the principal is not an externaluser, then he can read secret
element and the descendant elements."
It only means that internalUser (who is not externalUser) can read Secret
and the descendant elements but
not mean that the externalUser can read other Header elements and Body
elements.
But it is ok, you can fix that problem by adding one more rule.

The point is that the test case I described is the simplest policy I could
imagine.
Please consider more complicated policies such as:

Access must be denied if internalUser requests Secret element in weekend.
Access must be denied if the total money is greater than $1,000.
Access must be denied if the companyName is "XXX" and the principal is
"YYY"
Access must be denied if the principal is the externalUser and the
destination company name is not the
principal's company
...

Other policy would be more hierarchical policy specification such as:
InternalUser can read Header element but cannot read Secret element except
for the mode element.
Please suppose that the role has hierarchy in the structure and a policy
writer wants to specify sub-subject
takes precedence policy like: Internaluser is not allowed to read secret
element but manager is allowed to read.
(Manager is also InternalUser but more specific role)
...

If XACML allows only grant policy, the policy specification could result in
many repititions of the same
negative conditions such as "if not weekend and less then $1,000 and so on"
In addition to that, if there are
100 grant rules in the policy, you have to verify 100 grant rules to check
whether there is a rule that holds.

If XACML allows (or allows to extend) to write deny or other semantic
basis, that can reduce the repitition
greatly as well as the time to compute the decision because the system can
determine the denial if one of
the <deny> policy holds.

Best regards,
Michiharu Kudo

From: Tim Moses <tim.moses@entrust.com> on 2001/12/19 00:55

To:   "'XACML'" <xacml@lists.oasis-open.org>
cc:
Subject:  [xacml] What are we arguing about?

Colleagues - The proper way to apply the current proposed language schema
to Michiharu's use case is shown below.  It really isn't very different
from what Michiharu has proposed.

<?xml version="1.0" encoding="UTF-8"?>
<policy name="corporate confidentiality policy" issuer="xyz.com">
    <and>
        <policy name="permit internal users to read purchase orders" issuer
="xyz.com">
            <target resourceClassification="purchaseOrder"
propagationAlgorithm="someURI">

<!--The propagation algorithm defines the transformation from the resource
identifier
obtained from the saml authorization request and the resource
classification identified in the target element.  In this case, the
indicated algorithm truncates the path

expression-->

                <actions>read</actions>
            </target>
            <rule><preCondition>
                <equality>
                    <referencedData location
="saml/Attribute/AtributeName/Role"/>
                    <hardCoded value="internalUser"/>
                </equality>
            </preCondition></rule>
        </policy>
        <policy name="prevent external users from reading secret elements"
issuer="xyz.com">
            <target resourceClassification="secret" propagationAlgorithm
="someURI">
                <actions>read</actions>
            </target>
            <rule><preCondition>
                <not><equality>
                    <referencedData location
="saml/Attribute/AtributeName/Role"/>
                    <hardCoded value="externalUser"/>
                </equality></not>
            </preCondition></rule>
         </policy>
    </and>
</policy>

NB  This instance assumes that we eventually agree some changes to the
schema for the sake of efficiency.  But it is faithful to the principles.

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>