5.2 Introducing Role-Based Security
The .NET Framework provides a generic role-based security mechanism to represent the identity and roles of the
Figure 5-1. Role-based security
Regardless of the underlying source of user information, .NET's role-based security interfaces provide a standard mechanism through which you can make runtime security decisions based on the identity and roles of a user. For example, you can make decisions, such as:
.NET's abstraction of the role-based security interfaces from the underlying authentication and authorization mechanisms make it relatively easy to change from one mechanism to another should the need arise. We provide a detailed coverage of .NET's role-based security mechanisms in Chapter 10.
5.3 Introducing Code-Access Security
An important goal of the .NET Framework is to facilitate the development of highly distributed, component-based systems. With the .NET Framework, you can easily create applications that utilize code from different publishers, dynamically loading assemblies from different locations as required. Internet Explorer is an early example of this flexible architecture: downloading and executing .NET controls on demand, and giving the
Traditionally, code executes using the identity, roles, and permissions of the user that runs it. As we discussed in the previous section, role-based security is important for ensuring system security. However, in a connected world where distributed systems and highly mobile code are the order of the day, it is insufficient to base system security decisions solely on the permission granted to the user running an application. Faulty code can damage files to which the user has access, or,
Many companies tackle the problem of code security by "locking down" their users' desktops, restricting the applications that people can install and run. This heavy-handed approach requires extensive engineering and support resources to maintain and
The .NET Framework includes an important new feature known as code-access security (CAS) , which provides fine-grained control over the operations and resources to which managed code has access. With CAS, access is based on the identity of the code, not the user running it. Some examples of operations protected by CAS include:
Other pre-.NET technologies have
5.3.1 Evidence, Security Policy, and Permissions
The three key elements of code-access security are evidence , security policy , and permissions . When the runtime loads an assembly, it inspects various characteristics of the assembly (evidence) to determine an identity for the code. Based on a configurable set of rules (security policy), the runtime uses the assembly's evidence as input to a process named policy resolution . The result of policy resolution is a set of protected operations and resources to which the code within the assembly has access (permissions).
In the course of execution, code attempts to perform a variety of operations. If the code attempts to perform a protected operation, then the runtime will look at the permissions granted to the assembly containing the code and determine if they include the permission necessary to allow the action to go ahead. Figure 5-2 illustrates the relationship between evidence, security policy, and permissions during policy resolution. Here is a detailed account of each element:
Figure 5-2. Evidence, security policy, and permissions
5.3.2 Windows Security and Code-Access Security
CAS does not replace or circumvent the security provided by the Windows operating system. As shown in Figure 5-3, CAS is effectively another layer of security that managed code must pass through before it can interact with protected system resources, such as the hard disk and the Windows registry. The important difference between CAS and Windows security is that CAS bases security decisions on the identity of the code performing an action, whereas Windows bases security decisions on the identity of the user on whose
Figure 5-3. Relationship of CAS and OS security
For example, if a managed application
As Figure 5-3 also shows, CAS controls the ability of managed code to call unmanaged (native) code, such as the Win32 APIs. This is important, because when a managed application is allowed to call into unmanaged code, there is no CAS layer to restrict what the unmanaged code can do on behalf of the managed code. Instead of having permissions based on code identity, you are back to the situation where only the permissions of the current user restrict the code's actions. As we discussed at the beginning of this section, this is not sufficient when dealing with mobile code from
Finally, CAS also controls access to functionality that is internal to the CLR and does not affect operating system resources, such as the ability to create an application domain. We discuss CAS in greater detail in Chapter 6 through Chapter 9.