[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] [model] implementing global "deny" using 0.8 andmeta-policies
I also support Anne's proposal. I think this technique deal with the
distributed scenario nicely. I said the similar idea that uses an external
function to call sub applicable policies in the policy model con-call on
Dec. 17 but Anne's description is much more concrete and easy to
understand. For the global deny policy, I agree that this technique is
useful to specify the global deny semantics. If this technique is agreed,
we may need more intuitive name for the externalFunction.
p.s. I may not be able to attend tomorrow morning concall.
Best regards,
Michiharu Kudo
From: ernesto damiani <edamiani@crema.unimi.it> on 2002/01/19 20:07
To: Tim Moses <tim.moses@entrust.com>, xacml@lists.oasis-open.org
cc:
Subject: 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC