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!

Code group hierarchy

Code groups are defined in a hierarchy whose root is the group containing all code. If code is a member of the parent code group then its child code groups are tested for membership. Otherwise, a given piece of code cannot be a member of any of the descendent code groups below a parent code group it does not belong to. A simple example follows to illustrate the hierarchy of code groups concept.

Evaluation of code groups for a particular piece of code begins at the top – all code belongs to the root code group, so next membership in the four immediate child groups is tested (in any order). Suppose in this example code is published by Microsoft and is in the Intranet zone – the leftmost and second from right code groups in the diagram above. Next the children of these nodes only are tested – suppose this code has strong name “MS.Office” and is from site “localweb”. If these groups had children they would be further tested, but since they don’t the process completes. Result is that the code belongs to these code groups: All code, Publisher: Microsoft, Zone: Intranet, Strong name: “MS.Office”, and Site “localweb”. The permission sets associated with these code groups would then be combined together to determine the set of permissions allowed this code.

The arrangement of code groups into a hierarchy allows the policy configuration to be partitioned and refined – child code groups of a parent code group are only going to impact code that is a member of the parent. The hierarchy model allows administrators to manage policy configuration in terms of groups of code with further levels of refinement (in a flat model, the potential interaction of all code groups makes it much more difficult to manage as the number of groups grows). A performance benefit is gained as well since as code group membership is evaluated, large sub-trees can be excluded from further evaluation making the policy operation correspondingly faster.

Thus the permission sets (and therefore the permissions) policy may grant code are determined from the code groups it belongs to (see Policy decision and permission grant process for more detail). This allows the administrator to configure policy to trust some code more than others by making that code a member of a group with additional permissions associated with it.

The security policy hierarchical model does not allow multiple inheritance, however there are strategies administrators can use to achieve similar aims. First, instead of putting a code group under multiple parent code groups, consider if the code group can be elevated to be a peer of those code groups. Alternatively, often the new code group can become the single parent with existing code groups subsidiary to it: this achieves the same effect that code must belong to both but avoids duplicate code groups. Where the specificity of certain parent code groups is necessary, a common named permission set can be associated with new duplicate code groups under the respective parents.