Title: RE: [xacml] [model] implementing global deny using 0.8 and meta-policies I support this proposal. I believe it could deal smoothly with the distributed scenario Anne described many times during the last concalls. It goes in the same direction of a previous suggestion of mine (deal with composition and distributed deployment at the ApplicablePolicy level), but does it far better. However, I would suggest some minor observations/amendments (otherwise there is no fun :-)) 1. Maybe this is trivial, but any change to the current schema should keep policies fully embeddable in the Applicable policy element, besides being able to point to them using external functions. In simple environments there will be only one local policy, stated in a single document. 2. I happen not to like very much using the word meta-policy to describe this proposal, for several reasons some of which would be too long to explain in this message. Basically, I regard Anne's technique mainly as a way to define how a global policy can be deployed in distributed, independently maintained retrieval units. In passing, it also solves the problem of stating which criterium should be applied to compose the outcome of such units (this is essential when deny is a possible outcome, as the criterium may have an impact on what actually needs to be retrieved), but I cannot convince myself this requirement is equally important. I believe (but would like to hear the opinion of the industrial researchers on this one) that there will be a default policy composition technique that will be used 99.9% of the times. Therefore, in the schema I would prefer to concentrate the deployment description functionality in a new element, perhaps called ApplicablePolicies , possibly defined as an extension of the base (Applicable)Policy type. This element could optionally (via an attribute) specify the composition criterium as well. Tim, what are your views? Rgds Ernesto Prof. Ernesto Damiani Dipartimento di Tecnologie dell'Informazione Università di Milano - Polo di Crema Via Bramante 65 26013 Crema, Italia tel 0373-898240 fax 0373-898253 ----- Original Message ----- From: Tim Moses To:
xacml@lists.oasis-open.org Sent: Friday, January 18, 2002 8:35 PM Subject: RE: [xacml] [model] implementing global deny using 0.8 and meta-policies Colleagues - For the record, I support Anne's proposal. I think we might consider some minor schema changes to better accommodate the described approach. But, in principle, I am in favour. Can we hear from anyone who feels that this approach is inadequate? Naturally, a well-reasoned explanation of its deficiencies would be most helpful. Thanks a lot. All the best. Tim. ----------------------------------------- Tim Moses Tel: 613.270.3183 -----Original Message----- From: Anne Anderson [ mailto:
Anne.Anderson@Sun.com ] Sent: Thursday, January 17, 2002 3:46 PM To:
xacml@lists.oasis-open.org Subject: [xacml] [model] implementing global deny using 0.8 and meta-policies Implementing global deny semantics using schema 0.8 and meta-policies USE CASE: policy is to deny access to Principal Anne Anderson under all conditions. The policy is distributed across many sub-policies, which are all combined to produce the global policy that is to be applied. Michiharu's concern was with needing to put something like <not> <equal> <valueRef entity= principal >saml:Subject/NameIdentifier/Name</valueRef> <value> Anne Anderson </value> </equal> </not> into every sub-policy if there was no global deny syntax. My proposed solution depends on the idea of having meta-policies. I think meta-policies solve multiple problems: 1. where do I get policies , 2. knowing when you have obtained all the relevant policies, 3. knowing how to combine policies 4. being able to implement global deny and meta-policies does not introduce any new syntax. It is just very explicit in specifying what applicable policy means. SOLUTION Each PDP (or PRP) needs to be configured with a single policy that serves as that PDP's meta-policy . The syntax of this single policy is exactly that in 0.8. This meta-policy determines where and under what conditions various sub-policies are retrieved. I may not be using <externalFunction> correctly, or the subpolicies may need more enclosing namespace information, but I hope these examples will give the idea. The final example shows how global deny semantics are implemented. EXAMPLE SIMPLE META-POLICY FOR DISTRIBUTED POLICIES: <?xml version= 1.0 encoding= UTF-8 ?> <applicablePolicy xmlns=... issuer= <identity that ultimately controls policy for this PDP> policyName= ... > <!-- target omitted, since this policy applies to all targets --> <policy> <and> <externalFunction>
http://www.site1/policy1.xml </externalFunction> <externalFunction>
http://www.site2/policy2.xml </externalFunction> ... </and> </policy> </applicablePolicy> What is found at each of the <externalFunction> locations is another <applicablePolicy>, which may be more specific as to which resources it applies to (that applicablePolicy in turn may refer to still other policies). If one of these <applicablePolicy> elements does not apply to the current request, then the result is does not apply and does not affect the result of the <and> evaluation. META-POLICY THAT USES SUB-POLICIES BASED ON RESOURCE <?xml version= 1.0 encoding= UTF-8 ?> <applicablePolicy xmlns=... issuer= <identity that ultimately controls policy for this PDP> policyName= ... > <!-- target omitted, since this policy applies to all targets --> <policy> <or> <and> <equal> <valueRef>saml:Resource</valueRef> <value> file:/host1/* </value> </equal> <externalFunction>
http://www.site1/policy1.xml </externalFunction> </and> <and> <equal> <valueRef>saml:Resource</valueRef> <value> file:/host2/* </value> </equal> <externalFunction>
http://www.site2/policy2.xml </externalFunction> </and> ... </or> </policy> </applicablePolicy> META-POLICY THAT IMPLEMENTS GLOBAL DENY SEMANTICS <?xml version= 1.0 encoding= UTF-8 ?> <applicablePolicy xmlns=... issuer= <identity that ultimately controls policy for this PDP> policyName= ... > <!-- target omitted, since this policy applies to all targets --> <policy> <and> <not> <equal> <valueRef entity= principal >saml:Subject/NameIdentifier/Name</valueRef> <value> Anne Anderson </value> </equal> </not> <or> <and> <equal> <valueRef>saml:Resource</valueRef> <value> file:/host1/* </value> </equal> <externalFunction>
http://www.site1/policy1.xml </externalFunction> </and> <and> <equal> <valueRef>saml:Resource</valueRef> <value> file:/host2/* </value> </equal> <externalFunction>
http://www.site2/policy2.xml </externalFunction> </and> ... </or> </and> </policy> </applicablePolicy> For administrative ease in a more realistic situation, the set of globally denied attribute/value combinations would be placed in one <externalFunction> policy. Anne -- Anne H. Anderson Email:
Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <
http://lists.oasis-open.org/ob/adm.pl >