RE: [xacml] What are we arguing about?

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:]

Sent: Thursday, December 20, 2001 7:14 AM

To: Tim Moses <tim.moses

Cc: 

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 <> on 2001/12/19 00:55

To:   "'XACML'" <>

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>