C# Security Features

Security is an important aspect of software development nowadays, and C# in its very architecture has this feature, present in various forms. There are some holy-water droplets to drink before eating the topic to self-satisfaction. And those include

- Permissions
- Type-safety
- Security Policy
- Principal
- Authentication
- Authorization

The .NET Framework offers code access security and role-based security to help address security concerns about mobile code and to provide support that enables components to make decisions about what users are authorized to do. These security mechanisms are designed to have a simple, consistent model so that developers familiar with code access security can easily use role-based security, and vice-versa.

Permissions

There are three kinds of permissions : Code permissions, Identity Permissions & Role-based permissions . The namespace System.Security.Permissions is responsible for it and provides support in implementing custom permission classes also.

The primary uses of permissions are as follows:

- code can request the permissions it needs to access resources or perform operations
- the runtime can grant permissions to code, based on characteristics of the code’s identity, on what permissions were requested, and on how much the code is trusted
- code can demand that its callers have specific permissions.

Type-safety

Type-safe code accesses only the memory locations it is authorized to access. It cannot, for example, read values from another object’s private fields. Type-safe code accesses types only in well-defined, allowable ways. During Just-In-Time (JIT) compilation, an optional verification process examines the Microsoft Intermediate Language (MSIL) in an attempt to verify that the MSIL is type-safe. This process is skipped if the code has permission to bypass verification.

Code that is not verifiably type-safe can attempt to execute if security policy allows the code to bypass verification. However, because type-safety is an essential part of the runtime’s mechanism for isolating assemblies, executing unverifiable code can cause problems that crash other applications as well as the runtime itself. Also, security cannot be reliably enforced if the code violates the rules of type-safety.

Security Policy

Security policy is the configurable set of rules that the Common Language Runtime(CLR) follows when it decides what it will allow code to do. Administrators set security policy, and the CLR enforces it. The CLR ensures that code can access only the resources and call only the code that security policy allows it to access.Whenever an attempt is made to load an assembly, the runtime uses security policy to determine which permissions to grant to the assembly. After examining information called evidence that describes the assembly, the runtime uses security policy to decide how much the code is trusted and, therefore, what permissions to grant to that assembly. Evidence includes, but is not limited to, the code’s publisher, its site, and its zone. Security policy also determines which permissions to grant to application domains.

Continues…