Section 9.5. Security

9.5. Security

Despite the precedent I set earlier in this book, I'm going to discuss security toward the beginning of this chapter, for several reasons:

• Security is what you will encounter most often from a management perspective.

• The .NET Security model is probably the most radical shift from tradition among all elements of the Framework.

• Most other elements of the .NET Framework depend on security.

• It is just too darn important.

Code access security is an entirely new concept introduced by the .NET Framework. Traditional security models rely solely on the identification of the user and in turn apply the appropriate permissions. .NET supplements this model with another model running in parallel, the code access security model. In code access security, the running code, not the user, is identified using "evidence" of its origin, and permissions are applied depending on that evidence.

This is very useful in many scenarios, but perhaps the most evident example is the case of spyware and viruses. In a code access security model, you can limit the functionality available to an application. This can prevent an Internet-based application from modifying the registry, accessing the network, accessing certain files, or performing virtually any action you choose to define.

As I mentioned earlier, code is identified based on evidence. Table 9-3 lists different types of evidence that can be exposed.

Table 9-3. Types of evidence

Evidence type	Description	Example(s) of condition
Zone	The zone that the assembly originated from. This is identical to the zone displayed on the Internet Explorer status bar.	My Computer Intranet Internet
Site	The site that the assembly originated from. When applying conditions, any URL starting with this value is valid.	http://microsoft.com/ http://test.com/public
URL	The URL that the assembly originated from. Similar to the site evidence type, but more granular. When applying conditions, exact locations of assemblies can be specified.	http://microsoft.com/* http://test.com/test.dll
Application directory	Indicates whether the assembly is located within the folder structure of the application.	N/A
Strong name	A strong name refers to the Public Key, Name, and Version of the assembly.	Public Key: A3AD... Name: Microsoft.Test Version: 1.1.0.0
Publisher	The publisher of the assembly. This will be exposed only if the assembly is digitally signed with a certificate.	Name: Microsoft Issuer Name: Verisign Hash: 23ASD3...
Hash	A simple MD5 or SHA1 hash of the assembly. When applying conditions, this ensures the exact binary assembly.	23ASD3...
Custom	Any other information needing to be interrogated about the assembly by the runtime.

From the type of evidence exposed, the runtime places the code into one or more code groups. This is done by evaluating the membership condition of each defined code group. An example of a membership condition is "Site = http://www.microsoft.com/". The default code groups correspond to zones in Table 9-4.

Table 9-4. Default permission sets for code groups

Code Group	Permission Set
All_Code	Nothing
My_Computer_Zone	FullTrust
LocalIntranet_Zone	LocalIntranet
Internet_Zone	Internet
TRusted_Zone	Internet
Restricted_Zone	Nothing

Each code group is associated with a single permission set, which is, as you might have guessed, a set of permissions. Each permission in the permission set is configured individually. Many different permissions exist, most corresponding to libraries within the .NET Class Library. There are too many permissions to list and describe here, so I recommend firing up the .NET Configuration MMC shown in Figure 9-2. By double-clicking a specific permission in the right pane, you can view the applicable parameters available for that permission and how the permission is configured for that permission set.

Figure 9-2. .NET Configuration MMC permission list

This is obviously a lot of information to digest, so I recommend diving into the configuration panel to get some hands-on experience. Also, keep in mind that the information presented is from a system administration perspective. Plus, the developers among us can utilize permissions within code and libraries, which introduces virtually limitless options for further levels of security.

9.5.1. Role-Based Security

.NET also provides a robust model for role-based security. This model relies on first identifying the user and the user's roles. Once the user is identified, access checks are made within the application to determine, based on the roles, whether a user is authorized to use a resource or perform an action.

A user is identified using a method of authentication. Three types of authentication are provided within the .NET Framework:

• "Windows" authentication can be used in any type of application. This will use local SAM or Active Directory credentials for the current user. To use this with a web application, you must configure IIS to allow Basic, Digest, Integrated Windows Authentication, or Certificates. See Chapter 8 for information on configuring IIS this way.

• "Forms" authentication is a custom scheme Microsoft built for web applications. In simple scenarios, forms authentication is configurable entirely within web.config. In more complex scenarios, forms authentication can be extended to interface with a database or directory for authentication.

• "Passport" is Microsoft's attempt at completely centralized authentication. .NET Framework provides authentication for web application users into Passport.

In addition to these authentication types, .NET provides a schema to implement custom authentication schemes, most likely using an organization's existing infrastructure.

Once a user is authenticated, authorization comes into play. You can implement authorization in numerous different ways depending on the type of application. Windows applications typically perform authorization checks before a user attempts an action. Web applications often perform authorization checks before a user accesses a URL.

The security administration for web applications is much more flexible because of the introduction of security settings into web.config. Windows applications cannot be afforded this flexibility because of the obvious security risk of a user being able to manipulate the settings in the application configuration file.

Example 9-2 shows a very simple authentication and authorization scheme defined in web.config.

Example 9-2. Simple web application role-based configuration

<configuration>   <system.web>     <authentication mode="Forms">       <forms loginUrl="login.aspx">         <credentials passwordFormat="Clear">           <user name="user" password="password" />           <user name="administrator" password="password" />         </credentials>       </forms>     </authentication>     <authorization>       <deny users="?" />       <allow users="*" />     </authorization>   </system.web> </configuration>

The authentication element specifies forms authentication, and the forms parameters are defined within. In this case, the users are actually defined within the forms element. Keep in mind this would be practical only for the simplest of cases. Several pitfalls of this approach are as follows:

• No roles can be assigned to users. This allows only two levels of security, authenticated and anonymous, unless you explicitly name users in the authorization section, which is discouraged because of the maintenance involved.

• Changes made to web.config cause the application to restart. This is less than optimal in a high-traffic situation or when changes must be made very often.

• The user store is isolated from other applications, forcing a separate user store for each application.

The authorization section in Example 9-2 reflects the simplicity of the inline user store. The authorization section lists two conditions. The first condition specifies that all anonymous users, abbreviated as ?, are denied. The second condition, which is redundant with the default configuration, specifies that all users are allowed. By the configuration being applied top down, this would disallow anonymous users and allow authenticated users.

A more practical, but more system-dependent, web.config is shown in Example 9-3.

Example 9-3. Practical web application role-based configuration

<configuration>   <system.web>     <authentication mode="Windows" />     <authorization>       <deny roles="DOMAIN\Banned Users"       <allow roles="BUILTIN\Administrators,BUILTIN\Users" />       <deny users="*" />     </authorization>   </system.web> </configuration>

This file specifies to use Windows security for authentication. The authorization section has several conditions, all based upon roles. As the file is evaluated, first the user is checked to see if he is in the Banned Users group. If so, he is denied access immediately. Next, Windows checks to see if he is either an administrator or a user with a normal account, and he is admitted if either of these is true. Finally, all other users are denied access.

Both Example 9-2 and Example 9-3 apply security to the entire directory structure in which web.config is located. For more granular security, you can place web.config files in subdirectories to specify different authorization logic. In this case, the authorization checks are merged between all web.config files in the hierarchy with the deepest subdirectory checks being evaluated first.

The machine.config file defines a single authorization condition: <allow users="*" />. This effectively allows in any user that has not met a condition specified in the web.config file for the application. In a security-sensitive environment, I recommend to modify the machine.config file and change the authorization condition to <deny users="*" />. This denies all users by default.