OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


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