.NET Security Programming

As we shall see in Chapters 7 and 8, there are two powerful approaches to security programming supported by the .NET Framework: role-based security and CAS. These two approaches to security programming are then explored further in the context of Internet and distributed applications in Chapters 9 and 10. We shall see these two terms defined more completely with supporting code examples in the relevant chapters to come, but for now, let's take a very brief look at these two major concepts.

Role-Based Security and Principals

Most people have at least an intuitive understanding of users and roles based on their experience using an operating system such as Windows 2000 or Windows XP. The idea is that you can control how certain users can access certain resources, such as files, registry entries, and so on. Thus, role-based security comes down to the two basic questions of authentication and authorization . The authentication question asks who you are, and the authorization question asks if you are permitted to perform the action you are attempting.

In role-based security programming, the word "you" in these two questions is represented by an object referred to as the principal . The principal object contains an identity property that represents the user ID that is running the current thread. We shall see in Chapter 7 exactly how to use role-based security to accomplish various security goals in .NET programs.

CAS, Evidence, Policy, and Permissions

Code Access Security (CAS) allows administrative control over the actions that code is permitted to perform. CAS is based on the idea that you can assign levels of trust to assemblies and restrict the actions of the code within those assemblies based on established permissions. CAS is closely related to the concept of evidence-based security. Evidence is the set of telltale information that is used by the CLR to make decisions about what code group the assembly belongs to and therefore what actions the code is allowed to perform. A piece of evidence might be the location from which the code originated or the digital signature that was used to sign the assembly, and so on.

Security policy is the configurable set of rules that is established by an administrator and used by the CLR to make CAS decisions. Security policy can be set at the enterprise, machine, user, or application domain level. Security policy is defined in terms of permissions. A permission is an object that is used to describe the rights and privileges of assemblies that belong to a code group to access various resources or undertake certain actions. In effect, policy maps permissions to evidence.

Assemblies can programmatically or declaratively request to be granted certain permissions. Security policy dictates what permissions will ultimately be granted to a given assembly. Security policy is based on a set of rules that administrators can set, and the CLR uses those rules to enforce the desired policy. The evidence, represented by the identity permissions, is used to determine which policy to apply according to the code group that the assembly belongs to. The CLR determines which permissions are to be assigned to a loaded assembly by evaluating its evidence. Evidence can refer to identity of the assembly, the digital signer of the assembly, and the origin of the assembly, including its URL, site, and Internet Zone. In Chapter 8, we shall see much more detail about how to program using use code access security.