How Does CAS Work?
CAS defines permissions sets—things that can be done by a set of code and membership conditions. To do this, CAS identifies and characterizes client code so the appropriate permissions for that code can be determined. So defining how you want code access security to work is all about defining what you want an application to be able to do—and not do—and then telling .NET how to figure out whether the code gets the permission set to work.
The next few sections connect the pieces of the system that define how CAS will make those determinations. After you have an understanding of how CAS settings are processed in an ASP.NET application, I'll show you how to create your own custom CAS policy and watch it in action.
Defining CAS in the web.config
The first tool in configuring the CAS is the web.config. There are actually two areas that define CAS settings in the web.config file. Both of these areas are located within the <system.web> tag in the web.config file. The first section is a <securityPolicy> tag, which has no attributes and contains a set of <trustLevel> tags.
The <trustLevel> tag is the tag that creates an association between a friendly name for the security policy and the actual policy file. The attributes for the trustLevel tag are:
- name—This is the friendly name for the policy file as it will be referred to below.
- policyFile—This is the file name of the policy file. If the policy file is not located in the same directory as the web.config file it is a full path to the policy file including the file name.
SharePoint, for instance, defines two <trustLevel> tags with names of WSS_Medium and WSS_Minimal. These are the two out-of-the-box policy files that SharePoint provides. As mentioned above, ASP.NET does not, by default, configure CAS at all—the default is Full trust. So if you're running ASP.NET without configuration you won't find these entries.
The second part of the configuration for the web.config is a <trust> tag, which is also placed in the <system.web> tag. The <trust> tag takes two attributes. They are:
- level—The level attribute corresponds to one of the <trustLevel> tag name attributes from above, or Full for full trust.
- originUrl—This specifies the host name for permissions that are defined only for certain hosts. This attribute is optional.
The entire <system.web> section and the <trust> tag can be encapsulated in a <location> tag if you need to allow for different locations with different trust levels or if you want to make sure that no one with an application in a subdirectory can override your settings. You can find out more about the <location> element in the MSDN documentation at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrflocationelement.asp.
Defining the Policy File
Using the two entries in the web.config file ASP.NET will load your CAS policy file. Now it's time to put something in that file that ASP.NET can use. To do that you may want to look at the configuration files already installed on your system by the framework. You can look in %WINDIR%\Microsoft.Net\Framework\V2.0.50727\CONFIG. The web_lowtrust.config is a simple file that you can start with to get comfortable with the file format. The web_hightrust.config is a reasonably complicated file that can be useful when you've gotten comfortable with the basic structure and how the files fit together.
The basic structure of the file is as follows:
<configuration>
<mscorlib>
<security>
<policy>
<PolicyLevel>
<SecurityClasses>
<SecurityClass> …
</SecurityClasses>
<NamedPermissionSets>
<PermissionSet>
<IPermission> …
</PermissionSet> …
</NamedPermissionSets>
<CodeGroup>
<IMembershipCondition> …
<CodeGroup /> …
</CodeGroup>
</PolicyLevel>
</policy>
</security>
</mscorlib>
</configuration>
The key parts of the file are the SecurityClasses, the NamedPermissionSets, and the CodeGroups. I'll examine each one in detail in the following sections.
Previous Page
