This article has been
excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors
of C# Corner.
Code access security and role-based security are the two main types of security
available to developers. Code access security deals with assigning permissions
to code, which allows code to access protected resources (such as disk files or
the registry) or carry out certain operations (such as accessing unmanaged
code). Code access security is built around the notion of permission objects,
which control who can access protected resources and what level of access is
granted. These permissions are usually based on a permission policy specified by
administrators on a given machine or domain.
Role-based security deals with identifying the user who is attempting to execute
the code, allowing or disallowing certain operations based on the privileges
that the user possesses. User identity is the underlying notion, but role-based
security also deals with permissions. Identities are closely tied to principals,
which contain information as to which roles a user has. The .NET Framework
provides an extensible architecture that allows developers to build their own
principals and identities for use with .NET role-based security.
The .NET Framework also introduces another security model, evidence-based
security. Evidence simply refers to input to the security policy about code.
Code that targets the CLR is deployed in single - or multiple-file units called
assemblies, which are the building blocks of .NET Framework applications. At
load time, the CLR examines each assembly for evidence identifying the assembly
- for example, the digital signature of the code's author and the location where
the code originates. Based on this evidence, the CLR security manager maps the
assembly to a code group. Code groups are defined to test for specific forms of
evidence and have permission sets associated with them. Assemblies that belong
to a code group receive the permissions defined by the associated permission
sets.
For illustrative purposes, suppose some assemblies belonging to an application
are downloaded to the client computer from a Web site. Based on evidence about
the assemblies such as the URL, zone, strong name, and Web site from which the
assemblies are downloaded, the security system can determine the proper set of
permissions to be granted to the assemblies. Evidence information can be
obtained from multiple sources - the CLR, Microsoft Internet Explorer, Microsoft
ASP.NET, and the operating system shell, depending on the source of the code.
When an assembly is loaded, the CLR policy system gathers the assembly evidence
and evaluates it in the context of the security policy. The CLR policy system
then determines which set of permissions it should grant to the assembly based
on the evaluated evidence and any specific permission requests that the assembly
makes.
Permission requests may be used to stipulate certain permissions or limit the
permissions granted to an assembly. Assembly publishers know that some
assemblies will operate properly only when granted a certain minimum set of
permissions and that other assemblies will never need certain permissions.
Depending on the form of permission request, the policy system may grant
permissions to an assembly or remove unnecessary permissions. The system may
even refuse to load the assembly, if the minimum set of permissions needed to
run the assembly is not granted by system policy. An assembly can never be
assigned more permission than the policy system would grant in the absence of
permission requests.
Security policy consists of a collection of code groups, each with associated
permissions to be granted based on the evidence obtained. Policy has two
aspects: permissions granted to code rather than to users and permissions
granted on a per-assembly basis. Code groups describe the permissions available
to assemblies acquired from a specific security zone, or those that are signed
by a specific publisher, and so forth. While the CLR ships with a default set of
code groups and associated permissions, system administrators can modify these
CLR security definitions to fit their needs. Almost any characteristic can be
submitted as evidence, provided that the security policy has a use for it. The
administrator merely needs to define a code group related to that evidence.
The procedure for granting permission involves evaluating the evidence to
determine which code groups are applicable at each of four levels (detailed
later): enterprise, machine, user, and application domain. The policy evaluates
these four levels in order and then creates a permission set that represents the
intersection of all four. System administrators may designate any policy level
as final, thus preventing the evaluation of policies at subordinate levels. For
example, an administrator can finalize policy for an assembly at the machine
level and prevent the application of user-level policies to that assembly. Once
the policy processing is complete, an initial set of permissions is created.
Assemblies may adjust these grants by making specific requests in three areas:
- The first step is to specify a minimal set
of permissions that the assembly must have to operate. If these permissions
are not present, the assembly fails to load and an exception is thrown.
- Next, an optional set of permissions may
be specified. While the assembly would like any of these permissions, it
still loads if they are not available.
- Finally, particularly obedient assemblies
may actually reject hazardous permissions that they don't need.
These three enhancement options are
accomplished as load-time declarative statements. At runtime, permissions are
evaluated based on the execution of code. Actions such as reading or writing
files, displaying dialog boxes, and reading or writing environment variables are
accomplished using .NET Framework methods that are included within the framework
security infrastructure. Thus the .NET Framework allows or disallows actions
based on the security policy without imposing additional work on the developer.
While programmers of managed classes that expose protected resources must make
appropriate security demands in their libraries, programmers who use the .NET
Framework class libraries to access a protected resource benefit from the code
access security system for free; they do not need to make any explicit security
calls.
Administrators may adjust the security policy by determining which permissions
are granted and then rely on the .NET Framework to handle all security
operations. Code access security prevents most attacks, and the verification of
code eliminates buffer overruns and other unexpected behaviors that can lead to
security susceptibility. Thus, applications and components are inherently
protected against the vast majority of security problems that have plagued
native code implementations.
Sometimes it is appropriate for authorization decisions to be based on an
authenticated identity or on the code's function. For example, financial or
business software may enforce security policy through business logic that
evaluates role information. The amount of a financial transaction may be limited
based on the role of the user making the request. Tellers may be allowed to
process transactions up to a certain dollar amount, whereas a supervisor may
need to process transactions involving higher amounts. The .NET Framework
provides services that enable applications to incorporate such logic easily,
building it around the concept of identities and principals. An identity may map
to the user logged into the operating system or may be defined by the
application. The corresponding principal encapsulates the identity, along with
any related role information - for example, the user's "group" as defined by the
operating system.
Conclusion
Hope this article would have helped you in understanding the
Security Choices for Developers and Administrators. See other articles on the website on .NET and C#.
|
The Complete Visual
C# Programmer's Guide covers most of the major components that make
up C# and the .net environment. The book is geared toward the
intermediate programmer, but contains enough material to satisfy the
advanced developer. |