The .NET Framework uses role-based security and code-based security mechanisms for protecting resources and code from unauthorized use. Click each security mechanism to learn more:
Role Based Security
--------------------
A role-based security model uses authenticated identity information about the user to determine which computing resources the user is authorized to use. The authenticated identity information typically consists of the user’s logon and the roles that are associated with the user. Role-based security in the .NET Framework also allows developers to use Microsoft Windows® user and group information, or to perform custom authentication and authorization by using generic principals and identities.
A role defines a group of related users of an application. For example, a banking application may impose limits on the withdrawal amounts that can be transacted, based on role. In this scenario, tellers may be authorized to process withdrawals that are less than a specified amount, whereas managers may be allowed to process withdrawals above the amount specified. Role-based security in the .NET Framework extensively uses two concepts: identities and principals.
An identity encapsulates the user’s logon name.
A principal encapsulates the membership information of the user’s role.
The runtime provides functionality to perform authorization checks by using identity and principal-related objects directly, or by using imperative or declarative permission checks. .NET Framework role-based security supports authorization by making information about the user, which is constructed from an associated identity, available to the current thread. The identity can be based on a Windows account, or it can be a custom identity unrelated to a Windows account.
Code based Security
-------------------
Code access security is a mechanism provided by the CLR to examine and enforce permissions granted by security policy. To prevent unintended code paths from exposing a security vulnerability, all callers on the call stack must be granted the necessary permissions.
Every application that targets the CLR must interact with its security system. When an application runs, it is automatically evaluated and given a set of permissions by the CLR. Depending on the permissions that the application receives, it either runs properly or generates a security exception. The local security settings on a particular computer ultimately decide which permissions the code receives.