[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC