Summary

.NET offers two types of security mechanisms—CAS and role-based security. These security mechanisms are defined on top of the security mechanism offered by the underlying OS.

CAS grants code access permissions to an assembly based on certain evidence about the origin or author of the assembly. The .NET Framework defines various code access permissions such as reading or writing files, changing environmental variables, displaying dialog boxes, and so on. The standard classes under .NET that deal with any security-sensitive operations are designed to perform the appropriate security check. If the assembly does not have the needed permissions, the security mechanism throws an exception of type SecurityException.

By default, the security access check is performed on all the callers in the call stack, which prevents luring security attacks.

Instead of relying on the standard classes to throw the SecurityException, a component can perform the security check by itself, or the code may deny itself certain permissions or assert certain permissions. When a permission is asserted, the common language runtime does not walk the stack to check if the permission has been granted to all the callers. Obviously, only those permissions that have been granted to the assembly can be asserted.

It is also possible to demand, assert, or deny code access permissions using attributes. The framework defines attributes corresponding to each of the code access permissions.

The common language runtime grants permissions to an assembly based on the information it obtains about the assembly. This information, called evidence, includes items such as the origin of the assembly or its author.

The exact permissions that are granted to an assembly are based on an entity on the local machine called the security policy. The security policy contains code groups and permission sets. A permission set is a named set of permissions and a code group maps a specific evidence to a specific permission set. The evidence is represented as a membership condition.

The security policy can be configured at four levels—enterprise, machine, user, and AppDomain. For the purpose of policy evaluation, the enterprise level gets the top priority, followed by machine, user, and AppDomain levels in that order. At each policy level, permissions from each matching code group are merged. In the final step, the granted permissions that are common to each policy level are selected and granted to the assembly.

You should be aware of a security issue with CAS: Although CAS is a good step toward preventing security attacks, it is still the first step. Hackers are still bound to find some holes in the security mechanism. Hopefully, the technology will mature with time.

Role-based security grants access to sensitive data based on the role a user belongs to. Under this mechanism, a user and his or her roles are encapsulated in an object referred to as the principal. Two types of principals come standard with .NET—generic and Windows-specific.

Each managed thread can be associated with a principal. The type of principal is dictated by a policy defined on the application domain.

There are three ways to perform a role check on the thread principal—explicit programming, imperative programming, and declarative programming.

.NET applications actually have two security contexts to deal with: one of the managed code and one of the underlying OS. .NET provides methods that the managed code can use to force the underlying physical thread to impersonate.

ASP.NET applications run in a separate worker process although the applications are hosted under IIS. By default, the worker process runs under an account ASPNET. However, the account to use can be configured from Machine.config.

ASP.NET applications have to deal with two levels of authentication. The first level of authentication is done by the IIS and the second level of authentication is handled by ASP.NET.

For IIS authentication, it is the responsibility of the client to provide credentials to the server. The .NET Framework provides some classes that the client code can use to provide the credentials.

ASP.NET authentication uses authentication providers to further authenticate the client.

The CAS and the role-based security mechanisms that are available to .NET applications are also available to ASP.NET applications. In addition, ASP.NET simplifies authorization by allowing you to define allowed and denied users in the application's Web.config file.

ASP.NET also provides a mechanism that allows you to force impersonation on the physical thread that is currently running the managed code.

In the next chapter, we will deal with another type of role-based security mechanism. This security mechanism is offered by COM+ but also is available to .NET applications.