Code Access Security Considerations

All data access is subject to code access security permission demands. Your chosen ADO.NET managed data provider determines the precise requirements. The following table shows the permissions that must be granted to your data access assemblies for each ADO.NET data provider.

 

Table 14.1: Code Access Security Permissions Required by ADO.NET Data Providers

ADO.NET Data Provider	Required Code Access Security Permission
SQL Server	SqlClientPermission Supports partial trust callers including Medium trust Web applications.
OLE DB	OleDbPermission [*]
Oracle	OraclePermission [*]
ODBC	OdbcPermission [*]
[*] At the time of writing, the OLE DB, Oracle, and ODBC providers support only Full trust callers on versions 1.0 and 1.1 of the .NET Framework. To use these providers from partial trust Web applications, you must sandbox your data access code, which necessitates a dedicated data access assembly. For an example that shows how to sandbox data access code and use the OLE DB data provider from a Medium trust Web application see Chapter 9, Using Code Access Security with ASP.NET.

If you use the ADO.NET SQL Server data provider, your code must be granted the SqlClientPermission by code access security policy. Full and Medium trust Web applications have this permission.

Whether or not code is granted the SqlClientPermission determines whether or not the code can connect to SQL Servers. You can also use the permission to place restrictions on the use of database connection strings. For example, you can force an application to use integrated security or you can ensure that if SQL Server security is used then blank passwords are not accepted. Violations of the rules you specify through the SqlClientPermission result in runtime security exceptions.

For more information about how to use SqlClientPermission to constrain data access, see "Data Access" in Chapter 8, "Code Access Security in Practice."