NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Policy Schema Overview

A security policy is expressed in terms of a hierarchy of code groups. Each code group is defined in terms of one membership condition and has a permission set associated with it. Corresponding to this model the policy schema contains nested code group schemas. Below I will first introduce the code group schema. I will then show how that schema fits into the policy schema.

Code group schema

Schema:

Reminder: Expressions marked with ‘%’ are optional

<CodeGroup class=”System.Security.Policy.CodeGroup”/>
   <IMembershipCondition class=”[class name of evidence class]”>
      [evidence type specific xml]
   </ImemebershipCondition>
   <PermissionSet> class=”System.Security.NamedPermissionSet”>
      <Name>[name of the permission set]</Name>
   </PermissionSet>
   (<Exclusive/>|<Levelfinal/>)%
   
   (

      (
      <CodeGroup …>
         [Code group xml possibly including other childcodegroups]
      )*
   )%
</CodeGroup>

Explanation: Each code group is defined by a membership condition (testing membership for some particular type of evidence about code). The IMembershipCondition expresses this. The class name that gets inserted in the IMembershipCondition tag is the name of the class implementing the membership condition. Following this tag are some membership condition specific xml elements (for instance if the evidence type used in the membership condition is zone then there would be a <zone> tag taking the zone value). More on different membership conditions below. A code group may have child code groups, indicated by another <CodeGroup..> , which itself could of course have child code groups (the above schema definition is recursive).

Example: Below is a code group defined in terms of evidence type zone with zone value Internet. It has the named permissions set ‘ForInternet’ associated with it, and contains one child code group.

<CodeGroup class="System.Security.Policy.CodeGroup">
<IMembershipCondition   class="System.Security.Policy.ZoneMembershipCondition">
                          <Zone>Trusted</Zone>
      </IMembershipCondition>
<PermissionSet class="System.Security.NamedPermissionSet">
          <Name>ForInternet</Name>
      </PermissionSet>

      <CodeGroup class="System.Security.Policy.CodeGroup">
            <IMembershipCondition       class="System.Security.Policy.ZoneMembershipCondition">
                       <Zone>Untrusted</Zone>
                  </IMembershipCondition>

<PermissionSet class="System.Security.NamedPermissionSet">
                       <Name>Nothing</Name>
                  </PermissionSet>

             </CodeGroup>
      </CodeGroup>

I will now discuss the different forms of standard membership conditions and, correspondingly, the difference in schema (for the <IMembershipCondition> tag)

We are currently supporting the following types of standard evidence that have corresponding standard membership conditions:

Site Membership Condition Schema:

<IMembershipCondition class=”System.Security.Policy.SiteMembershipCondition>
   <Site>[name of site of origin]</Site>
   
</ImembershipCondition>

Publisher Membership Condition Schema:

<IMembershipCondition class=”System.Security.Policy.PublisherMembershipCondition”>
   <x509Certificate>[certificate value]</x509Certificate>
   
</ImembershipCondition>

Strong Name Membership Condition Schema:

<IMembershipCondition class=”System.Security.Policy.StrongNameMembershipCondition”>
   <StrongName>[strong name value]</StrongName>
   
</ImembershipCondition>

URL Membership Condition Schema:

<IMembershipCondition class=”System.Security.Policy.URLMembershipCondition”>
   <Url>[Url of origin]</Url>
   
</ImembershipCondition>

Zone Membership Condition schema:

<IMembershipCondition class=”System.Security.Policy.ZoneMembershipCondition”>
   <Zone>[name of site of origin]</Zone>
   
</ImembershipCondition>

Policy Schema

A policy is comprised of a hierarchy of code groups. Since each code group has a named permission set associated with it there must also be a list of named permission set definitions as part of a policy. The below schema reflects this model.

Schema:

<Policy>
   <PolicyLevel class=”System.Security.Policy.PolicyLEvel” version=”1”>
      <NamedPermissionSets>
         (
         <PermissionSet …>
            [xml of permission set definition as in 5.2.]
         </PermissionSet>
         )*
      </NamedPermissionSets>
      <CodeGroups>
         (
         <CodeGroup class=…>
         …     //each code group referencing one permission set             by the permission set’s name
         </CodeGroup>
         )*
      </CodeGroups>
   </PolicyLevel>
</Policy>

Explanation: Each policy contains a non-empty list of named permission set definitions (sandwiched between the <NamedPermissionSets> tags) and a non-empty code group hierarchy (sandwiched between <CodeGroups>).