[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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 ...
<role = internalUser>
value greater than $1,000
I'll be a bit more rigorous in my sample policy instances.
All the best. Tim.
From: Michiharu Kudoh [mailto:KUDO@jp.ibm.com]
Sent: Thursday, December 20, 2001 7:14 AM
To: Tim Moses <tim.moses
Subject: Re: [xacml] What are we arguing about?
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
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
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
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
Access must be denied if the principal is the externalUser and the
destination company name is not the
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.
From: Tim Moses <firstname.lastname@example.org> on 2001/12/19 00:55
To: "'XACML'" <email@example.com>
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">
<policy name="permit internal users to read purchase orders" issuer
<!--The propagation algorithm defines the transformation from the resource
obtained from the saml authorization request and the resource
classification identified in the target element. In this case, the
indicated algorithm truncates the path
<policy name="prevent external users from reading secret elements"
<target resourceClassification="secret" propagationAlgorithm
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.
To subscribe or unsubscribe from this elist use the subscription
Powered by eList eXpress LLC