ADO.NET 1.1 Security Guidelines - Authorization

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Restrict unauthorized callers

Your code should authorize users based on a role or identity before it connects to the database. Role checks are usually used in the business logic of your application, but if you do not have a clear distinction between business and data access logic, use principal permission demands on the methods that access the database.


The following attribute ensures that only users who are members of the Manager role can call the DisplayCustomerInfo method:

[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
public void DisplayCustomerInfo(int CustId)
{
}

If you need additional authorization granularity and need to perform role-based logic inside the data access method, use imperative principal permission demands or explicit role checks as shown in the following code fragment:

using System.Security;
using System.Security.Permissions;

public void DisplayCustomerInfo(int CustId)
{
 try
 {
   // Imperative principal permission role check to verify that the caller
   // is a manager
   PrincipalPermission principalPerm = new PrincipalPermission(
                                                  null, "Manager");
   // Code that follows is only executed if the caller is a member
   // of the "Manager" role
 }
 catch( SecurityException ex )
 {
  . . .
 }
}

The following code fragment uses an explicit, programmatic role check to ensure that the caller is a member of the Manager role:

public void DisplayCustomerInfo(int CustId)
{
 if(!Thread.CurrentPrincipal.IsInRole("Manager"))
 {
   . . .
 }
}

Note Additionally, if you are using ASP.NET 2.0 and you have enabled the Role Manager feature, you can use the Roles API to perform role checks. For more information on using the Role Manager feature in ASP.NET 2.0, see "How To: Use Role Manager in ASP.NET 2.0." at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000013.asp


References


Restrict unauthorized code

By using .NET Framework code access security — specifically, code identity demands — you can limit the assemblies that can access your data access classes and methods.


For example, if you only want code written by your company or a specific development organization to be able to use your data access components, use a StrongNameIdentityPermission and demand that calling assemblies have a strong name with a specified public key, as shown in the following code fragment:

using System.Security.Permissions;
. . .
[StrongNameIdentityPermission(SecurityAction.LinkDemand,
                             PublicKey="002...4c6")]
public void GetCustomerInfo(int CustId)
{
}

To extract a text representation of the public key for a given assembly, use the following command:

sn -Tp assembly.dll

Note Use an uppercase "T" in the –Tp switch.


Because Web application assemblies are dynamically compiled, you cannot use strong names for these assemblies. This makes it difficult to restrict the use of a data access assembly to a specific Web application. The best approach is to develop a custom permission and demand that permission from the data access component. Full trust Web applications (or any fully trusted code) can call your component. Partial trust code, however, can call your data access component only if it has been granted the custom permission.

Note Although you can compile and strong name your Web Application and its assemblies in .NET 2.0, any strong-named assembly can satisfy and pass a StrongNameIdentityPermission link demand. Therefore it is recommended that you use the custom permission demand in this situation.


For an example implementation of a custom permission, see "How To: Create a Custom Encryption Permission" at http://msdn.microsoft.com/library/en-us/dnnetsec/html/HTCustEncr.asp


References


Restrict the application in the database

The preferred approach is to create a SQL Server login for the Windows account that the application uses to connect to the database. Then map the SQL Server login to a database user in your database. Place the database user in a user-defined database role and grant permissions to that role. Ideally, you should only grant the role execute access to the stored procedures used by the application.


For details about how to configure this approach, see "Configuring Data Access for Your ASP.NET Application in Chapter 19, "Securing Your ASP.NET Application and Web Services." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh19.asp


References

Personal tools