Medium Trust Overview
The default ASP.NET 2.0 application run mode is with full trust. However, if your application is required to run in a MEDIUM TRUST environment you will need to consider the impacts of medium trust on the design and development of your application. Applications that are being upgraded from ASP.NET 1.1 to ASP.NET 2.0 will have additional considerations because the security settings in 1.1 and 2.0 are slightly different.
Medium trust is often used in hosted environments were the application is isolated from other applications running on the same web server or web farm.
Medium trust security settings restrict your application in the following ways:
o OleDb Permission is not available.
o Event Log Permission is not available.
o Reflection Permission is not available.
o Registry Permission is not available.
o Web Permission is restricted.
o File IO Permission is restricted.
OleDb Permission
You cannot use the ADO.NET managed OLE DB data provider to access databases. However, you can use the managed SQL Server provider to access SQL Server databases. A good example is below of what works and what does not.
DOES NOT WORK WITH MEDIUM TRUST
//OLEDB Provider
With Command()
sqlCMD.CommandType = Data.CommandType.StoredProcedure
sqlCMD.Connection = sqlConn
sqlCMD.CommandText = "AddBlogComment"
sqlCMD.Parameters.AddWithValue("@BlogEntryID", BlogEntryID)
sqlCMD.Parameters.AddWithValue("@UserID", UserID)
sqlCMD.Parameters.AddWithValue("@Content ", Content)
sqlCMD.Parameters.AddWithValue("@RateBlog", RateBlog)
End With
sqlCMD.ExecuteNonQuery()
DOES WORK WITH MEDIUM TRUST
//Managed SQL Client Provider
Dim SQLAdapter As New Data.SqlClient.SqlDataAdapter
With SQLAdapter
.InsertCommand = sqlConn.CreateCommand()
.InsertCommand.Parameters.AddWithValue("@BlogEntryID", BlogEntryID)
.InsertCommand.Parameters.AddWithValue("@UserID", UserID)
.InsertCommand.Parameters.AddWithValue("@Content ", Content)
.InsertCommand.Parameters.AddWithValue("@RateBlog", RateBlog)
.InsertCommand.CommandType = Data.CommandType.StoredProcedure
.InsertCommand.CommandText = "AddBlogComment"
.InsertCommand.ExecuteNonQuery()
End With
Event Log Permission
Event Log Permission is not available. A custom policy is needed to address this issue, which means you are creating a custom modification of the “medium trust” security settings.
Reflection Permission
Reflection is a runtime namespace that allows you to obtain information about what is loaded allowing you to, use, create, and bind type instances and objects. Medium trust restricts reflection because runtime memory operations are restricted with medium trust.
o You cannot dynamically create an instance of a type
o You cannot bind dynamically created type instances to an existing object
o You cannot get the type from an existing object or invoke its
o methods or access its fields and properties.
o You cannot access attributes in your code
Your client application will need alternative methods for determining runtime information.
Registry Permission
Registry access is not permitted in medium trust and your application will need alternative methods for using information that would normally be obtained through registry calls.
Web Permission
Restrictions limit your application to communicate with a range of address you define within the element. An example is to define an origin URL within the tag with a specific URL with web permissions.
File IO Permission
The default medium trust settings only allow you to access files in your application’s virtual hierarchy. This means that you must specify custom “medium trust” settings to allow your application to work correctly if it’s using directories outside of the application hierarchy.
Considerations on Design
The code I have reviewed over the years for pre ASP.NET 2.0 made use of OLEDB providers, File IO, and Event Log access with less emphasis on reflection and web permission settings. New development in a medium trust environment would require examining the application model first from a security perspective then secondly from a functional perspective. Taking this approach will prevent the risk of application breaks at deployment time.
Data accesses will require ensuring that .NET managed providers are used or custom settings are allowed for OLEDB providers. The important key here is that some vendors only provide OLEDB drivers and you will need to know this before coding.
File access, if required, would also need custom security settings or a backend process to pickup and transfer files outside of the application. This means that your solution would require extra coding outside of the application scope to deal with file access restrictions. An example is a file or directory utility running as a service to sweep directories.
Event Logs, if needed, is also a custom setting otherwise you would need to build into your application a logging structure. An example is writing events to a text file or database table. The key here is that event logging to windows logs is quicker and easier so application performance may also be a consideration.
Reflection is a big consideration especially if you have applications where controls are specifically created to instantiate based on runtime conditions using reflection. In this case you would need to change how objects are handled within your application.
The bottom line is; be prepared to write more code to get around the restrictions with Medium Trust or plan on heavily customized security settings. Both of which, add overhead to the application development process.
References
http://msdn2.microsoft.com/en-us/library/f7ykdhsy.aspx
http://msdn2.microsoft.com/en-us/library/ms998341.aspx