Setting OLE-DB Provider and Event Log Permissions
So far, you have seen how the custom permissions allow the Data Access Application Block, Caching Application Block, and Cryptography Application Block to execute correctly in a custom partial trust mode. This final section shows how the limited OLE-DB permission specified in the policy definitions file, and the permission grant required by the Logging Application Block, work in this custom trust mode.

The <IPermission> element added to the policy definitions file specifies the only permissible connection string:

Figure 9. Permission Denied Exception: Using a non-permissible connection string raises a security exception.

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

This is a good way to prevent unauthorized access to databases when using OLE-DB. For example, if you change the connection string that the Data Access Application Block uses for the OLE-DB provider, the code access security mechanism will raise a security exception:

 <connectionStrings>
<add name="LocalOleDbConnection"
connectionString="Provider=SQLOLEDB;
Database=SecretOne; Server=.;Integrated Security=SSPI;"
providerName="System.Data.OleDb" />
...
</connectionStrings>

This non-permissible connection string causes the .NET Framework to raise an OleDbPermission exception when the code runs—before it even attempts to connect to the specified database, as you can see in Figure 9.

Figure 10. Accessing the Event Log with Custom Trust Mode. The Logging Application Block can access the Event Log in custom trust mode.

Notice also that the error message indicates that the Logging Application Block successfully added an entry to Windows Event Log. The <IPermission> element for the EventLogPermission added to the custom policy definitions file allows the code in the Logging Application Block to write to the Event Log. If you open Event Viewer, you will see the event, as shown in Figure 10.

Author's Note: The Logging Application Block may fail to write events to the Event Log if it is full, and the time before overwriting events prevents old events being deleted. You should ensure that the Application Event Log is not full before running the example to ensure that new entries can be written to the log.

You've now seen how easy it is to generate custom security policies for your ASP.NET applications, and use them to allow the features from Enterprise Library that would normally fail because of security exceptions to execute on your server. In other words, making these custom security policy changes extends the features of the Enterprise Library beyond just Windows applications, making them usable in your ASP.NET applications as well.