Authorization

The authorization process establishes if a user can retrieve and manipulate specific data. There are two approaches: your data access code can use authorization to determine whether or not to perform the requested operation, and the database can perform authorization to restrict the capabilities of the SQL login used by your application.

With inadequate authorization, a user may be able to see the data of another user and an unauthorized user may be able to access restricted data. To address these threats:

• Restrict unauthorized callers .

• Restrict unauthorized code .

• Restrict the application in the database .

Figure 14.3 summarizes the authorization points and techniques that should be used.

Figure 14.3: Data access authorization, assembly, and database

Notice how the data access code can use permission demands to authorize the calling user or the calling code. Code identity demands are a feature of .NET code access security.

To authorize the application in the database, use a least privileged SQL server login that only has permission to execute selected stored procedures. Unless there are specific reasons, the application should not be authorized to perform create, retrieve, update, destroy/delete (CRUD) operations directly on any table.

Note  

Stored procedures run under the security context of the database system. Although you can constrain the logical operations of an application by assigning it permissions to particular stored procedures, you cannot constrain the consequences of the operations performed by the stored procedure. Stored procedures are trusted code. The interfaces to the stored procedures must be secured using database permissions.

Restrict Unauthorized Callers

You 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"))   {     . . .   } } 

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.

For an example implementation of a custom permission, see "How To: Create a Custom Encryption Permission" in the "How To" section of this guide.

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."