Understanding the .NET Security Framework

The .NET Framework security services tackle these layers directly. At the center of this framework are objects that abstract a security policy, permissions, principals, and evidence.

Establishing a Security Policy

The security policy is the configurable set of rules that the Common Language Runtime (CLR) references as it determines what, if any, resources can interact with executing code. Network administrators specify the security policy, and the CLR enforces it. You can define a security policy at the enterprise, machine, user , and application levels. When the CLR loads an assembly, it takes the policies and assigns the code groups. During this assignment process, the CLR checks that no permission was denied at a higher level. If it was, the CLR does not assign the permissions. This guarantees that an application configuration cannot overwrite security settings of the enterprise.

Each security policy contains a set of identity permissions that the assembly needs for a code group . The CLR ensures that code can access only the resources and can only invoke code that the security policy allows it to invoke. When an assembly is loaded, the CLR also references the security policy to determine which permissions to grant to the loaded assembly. After reviewing information about specific code, known as evidence , the CLR references the security policy to decide how much the code is trusted, which in turn determines what permissions to grant to that assembly.

Identifying the Security Permissions

There are three kinds of permissions: code access, identity, and role based. The System.Security.Permissions object is responsible for abstracting permissions and provides support to implement custom permission objects. Code can request the permissions it needs to access resources or perform operations. The hosting environment can grant permissions to code based on characteristics of the code's identity, what permissions were requested , and how much the code is trusted. Code can also demand that its callers have specific permissions before executing.

Using Principal Objects

A principal object essentially abstracts a user. The .NET Framework security services support three types of principal objects: generic, Windows, and custom. A generic principal object represents an unauthenticated user and the roles assigned to him or her. A Windows principal object represents a user existing on a Windows server and the server-defined groups to which he or she belongs. An application can define a custom principal object in any way that is needed for that particular application. This can extend the basic notion of the principal's identity and roles. An application defining a custom principal must also provide an authentication module with types that implement the principal.

Supplying Identity Evidence

When an assembly is requested, the CLR searches for evidence of its origin. Evidence includes information about the code's publisher, its site, and its zone. Evidence works in conjunction with the security policy to determine which permissions are granted to application domains. Evidence answers the following questions being asked by the CLR:

• From which site does the assembly come?

• From which Uniform Resource Locator (URL) does the assembly come?

• From which zone does the assembly come?

• Who has signed the assembly?

• What is the strong (public or private key) name of the assembly?

Identity permissions and Code Access permissions are only granted if an assembly can show the proper identity evidence. Both are closely related and share the same underlying concept, being derived from the CodeAccessSecurity base class. Applications have no influence over the Identity permissions of an assembly. The CLR simply takes an assembly, examines its evidence, and assigns the identity permissions. To associate a set of identity permissions to a code group, the network administrator must specify them within the security policies.