.NET Security and Cryptography

The .NET security model is layered on top of the operating system's security model, and it can also interact with the security features of various server applications, such as SQL Server and Internet Information Services (IIS). Therefore, the security characteristics of a .NET application result from several factors, including how .NET security is configured, how the application components are programmed, as well as various security features that may be configured in Windows, ^[6] the network, ^[7] and other applications.

^[6] Throughout this chapter, the underlying operating system is assumed to be Windows 2000 or Windows XP.

^[7] For example, you can restrict access to your system from other IP addresses using IPSec (Internet Protocol Security).

Figure 7-1 shows how the .NET security model works on top of the Windows security subsystem. An administrator sets up user accounts and manages security policy on Windows using various Microsoft Management Console (MMC) snap-ins. An administrator is also responsible for managing .NET security configuration. Subsequently, when a user logs onto the operating system and then runs a .NET-managed application, the CLR authenticates the user and authorizes the actions of the program, and then passes those operations on to the security monitor of the operating system.

As an example of how .NET security can interact with the operating system, consider the fact that code always runs under some user identity. When you log on, you provide your username along with your password as proof that you are who you claim to be. Once your identity has been established, as a general rule, every action that you undertake when running any program is performed under your user identity. The result is that if an administrator has established an ACL (Access Control List) that denies you the right to read or write on a particular file, you will be unable to do so.

As we go through examples of securing objects in various ways throughout this chapter, it is important to recognize that regardless of what permissions may have been established using .NET security permissions, such a file may still be protected at the operating system level, which falls outside of the jurisdiction of the .NET platform.