Code Access Security: When Role-based Security Isn't Enough : Page 4

Code Groups
The final section of the CAS policy file to address is the <CodeGroup> section. Unlike the other sections of the file, which were not hierarchical in nature, the <CodeGroup> tag can be nested inside itself. This is, in fact, how it is set up by default. The first <CodeGroup> tag specifies a membership condition that includes all assemblies but grants them no permission. Under this are all of the individual code groups. The basic format of the <CodeGroup> tag has the following attributes:

• class—This is the class, from <SecurityClasses> above, which is associated with the <CodeGroup> tag. For the first, highest tag this is "FirstMatchingCodeGroup." The FirstMatchingCodeGroup tells .NET to locate the first matching code group (child of this node) and apply only its permissions. All of the subsequent tags typically use "UnionCodeGroup." This indicates that the permissions granted for all of the membership matches below should be granted to the assembly.
• version—Version always contains "1" even if working with ASP.NET 2.0.
• PermissionSetName—This is the name of the permission set (from above) to be granted to the code matching this code group.

Within the <CodeGroup> tag there should be one and only one <IMembershipCondition> tag. If you want a code group to apply to multiple assemblies that cannot be matched securely with one condition, simply put new <CodeGroup> tags in for each membership condition that you need. The IMembershipCondition is used to specify a few different kinds of matches. The basic types are listed below:

• StrongNameMembershipCondition—This condition matches any code that was signed by a specific strong name key. It takes a PublicKeyBlob attribute, which specifies the public key that matches the private key used to sign the assembly.
• PublisherMembershipCondition—This condition uses the Authenticode x.509v3 signature to determine whether the assembly can be trusted. This class takes the attribute of Certificate, which indicates the certificate to use for membership.
• HashMembershipCondition—This condition matches code based on its hash. In other words, the hash of the assembly after it was compiled. This class takes two attributes, the HashValue and the HashAlgorithm.
• SiteMembershipCondition—This condition matches code based on the site that it originated from. The Site attribute specifies the site to be matched, including wildcards.
• ZoneMembershipCondition—This condition matches code based on where the code was run from, as defined by Internet Explorer. This membership type takes an attribute of Zone, which matches the Internet Explorer zone name that the code is coming from.
• ApplicationDirectory—This condition matches assemblies based on their directory on the computer. The additional attribute, ApplicationDirectory, specifies the directory for the application to be matched.
• UrlMembershipCondition—This condition matches based on testing the assembly's URL. This membership condition takes an additional attribute of Url, which is used to provide the URL to match for.
• AllMembershipCondition—This condition matches all code.

The basic format of the <IMembershipCondition> has at least two attributes:

• class—Indicating the class name from above, which is to be used to determine membership.
• version—As with other classes, always set to "1" even in .NET version 2.

Added to these two attributes are whatever additional attributes are necessary to specify the condition to be matched.

Worth Tackling
The complexity of Code Access Security and the fact that it's not required by default for Web applications has made it something that few developers want to tackle, however, it is a tool that you can use to make your web applications more secure, whether you're working in SharePoint or just ASP.NET.

Previous Page