Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Using Enterprise Library in ASP.NET 2.0 Partial Trust Mode : Page 3

The Enterprise Library Application Blocks aren't useful only in Windows Forms applications; you can use them in ASP.NET too by downloading a set of patch files and configuring the security settings appropriately. Find out how.


advertisement
Looking Inside a Policy Definition File
Policy definition files, such as the one you are about to edit, can contain more than one version of the policy level, however those provided with the .NET Framework contain only a single version defined with the <policyLevel version="1"> element. The <policyLevel> element holds three sections:

  1. The <SecurityClasses> element contains a list of the permission classes referenced in the <NamedPermissionSets> element, including the name and the .NET Framework class that implements that permission set.
  2. The <NamedPermissionSets> element contains a list of the permissions for each of the classes listed in the <SecurityClasses> element.
  3. A series of <CodeGroup> elements that contain mappings between the permission classes and the specific permissions required by the .NET Framework.
In general, you will be concerned only with the first two sections. In the first, add the classes for which you want to set permissions that are not already included (such as permission to access an OLE-DB data source, encrypt data, or write to the Windows Event Log). In the second, add individual permission definitions for these classes and the classes already listed in the first section.

Adding Extra Security Permission Classes
The <SecurityClasses> element in a policy definitions file lists the permission classes, for example:

<SecurityClasses> <SecurityClass Name="AllMembershipCondition" ... /> <SecurityClass Name="AspNetHostingPermission" ... /> <SecurityClass Name="DnsPermission" ... /> ... more security classes here ...

You can add other permission classes for which you want to grant permissions. For example, this listing shows how you can add the OleDbPermission, EventLogPermission, and DataProtectionPermission classes:

<!-- added security permission classes --> <SecurityClass Name="OleDbPermission" Description="System.Data.OleDb.OleDbPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> <SecurityClass Name="EventLogPermission" Description="System.Diagnostics.EventLogPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> <SecurityClass Name="DataProtectionPermission" Description="System.Security.Permissions.DataProtectionPermission, System.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </SecurityClasses>

Notice how each definition in the code above specifies the assembly containing the class, the version, culture, and the public key token. Also note that the contents of the Description attribute should be all on one line, not wrapped to fit the page width as shown here. See the tables at the end of the HTML document provided with the Partial Trust Patch for a list of the permissions required by Enterprise Library when not running in Full Trust mode.

Granting Specific Security Permissions
Having added security classes to the <SecurityClasses> section in the policy definitions file, you can now add or edit the individual permission grants within the <NamedPermissionSets> section. This section contains a series of <PermissionSet> elements, one of which has a Name attribute value of "ASP.Net." This is the element that sets permissions for ASP.NET applications. Inside this element is a series of <IPermission> elements that map to the classes in the <SecurityClasses> section. For example, the default contents of the medium trust policy definitions file contains:



<NamedPermissionSets> ... <PermissionSet class="NamedPermissionSet" version="1" Name="ASP.Net"> <IPermission class="AspNetHostingPermission" version="1" Level="Medium" /> <IPermission class="DnsPermission" version="1" Unrestricted="true" /> <IPermission class="EnvironmentPermission" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME" /> <IPermission class="FileIOPermission" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" /> ... more security permissions here ... </PermissionSet> ... more permission sets here ... </NamedPermissionSets>

The preceding configuration shows how the .NET Framework specifies settings for ASP.NET. For example, under the Medium Trust setting, ASP.NET must be able to read certain environment variables and access an application's own folders (declared as $AppDir$) to execute successfully.

If the policy definition file already contains a definition for the permission you want to grant or change, you simply edit the existing <IPermission> element. For example, the default in Medium Trust mode for the PrintingPermission class allows access only to the default printer:

<IPermission class="PrintingPermission" version="1" Level="DefaultPrinting" />

To permit access to any printer, edit the file to change the Level attribute value:

<IPermission class="PrintingPermission" version="1" Level="AllPrinting" />

To use the features of Enterprise Library, you'll usually have to modify the existing <IPermission> element for the SecurityPermission class. For example, the web_mediumtrust.config file contains the following <IPermission> element:

<IPermission class="SecurityPermission" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration"

To use the serialization features of the .NET Framework, something that occurs in several places within Enterprise Library, you must add permission to use serialization formatters by appending the SerializationFormatter flag:

<IPermission class="SecurityPermission" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration, SerializationFormatter"

In addition to updating existing <IPermission> element values, in most cases you will have to add new <IPermission> elements to the <NamedPermissionSets> section of the file to allow Enterprise Library to execute features normally prevented in your chosen trust mode. These elements must, of course, match the <SecurityClass> elements you added to the <SecurityClasses> section of the policy definitions file.

For example, earlier you saw how to add the OleDbPermission, EventLogPermission, and DataProtectionPermission classes to the <SecurityClasses> section. In the <NamedPermissionSets> section, within the ASP.NET <PermissionSet> element, you can add an <IPermission> element that allows the Enterprise Library Data Access Application Block to use an OLE-DB data provider:

<!-- custom OLEDB permission --> <IPermission class="OleDbPermission" version="1"> <add ConnectionString="Provider=SQLOLEDB;Database=..." KeyRestrictions="" KeyRestrictionBehavior="AllowOnly"/> </IPermission>

Notice how you can use the properties of the OleDbPermission class, through attributes in the <IPermission> element, to specify limitations on the use of this permission. In the listing above, the combination of attributes allows use of an OLE-DB provider, but only with the connection string specified for the ConnectionString attribute. If code attempts to use any other connection string, the code access security system within the .NET Framework will raise a security exception and prevent execution.

The custom policy definitions file can also specify permission grants for the two other classes, EventLogPermission, and DataProtectionPermission, previously shown added to the <SecurityClasses> section. The syntax and the names of the attributes (and, in some cases, child elements) depends on the actual security class. For the EventLogPermission class, you use a child element named <Machine> to specify the name of the machine hosting the Event Log and the access permission level. The following example specifies the local machine Event Log, and allows full access ("Administer"), which is usually the minimum level that allows writing to the Event Log:

<!-- custom Event Log permission --> <IPermission class="EventLogPermission" version="1"> <Machine name="." access="Administer"/> </IPermission>

To allow ASP.NET to access the .NET data encryption and decryption features when using the Cryptography Application Block, you use the DataProtectionPermission class. This <IPermission> element sets the Flags property of the DataProtectionPermission class to allow code to perform both encryption and decryption:

<!-- custom Data Protection permission --> <IPermission class="DataProtectionPermission" version="1" Flags="ProtectData, UnprotectData" />

Author's Note: To discover the permission classes you need to configure, use the tables at the end of the Partial Trust Patch HTML document. To find the properties of these and other security classes you want to configure, look up that class in the .NET SDK. The list of members shows the public properties. Following the links for a property should provide a list of valid values for that property—you can use these as attribute values in the <IPermission> element. The SDK also tells you which assembly contains the permission class. After locating the assembly for a permission class, you can usually obtain the public key token value and version number using the Microsoft .NET Framework 2.0 Configuration utility available from the "Administrative Tools" section of your Start menu. Drill down in the tree view through My Computer, Runtime Security Policy, and Machine, and open the Policy Assemblies list.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap