Role-based security (RBS) is a
common security model in contemporary computing. When users wish to
access a computer system, they must first prove their
identity—a process known as
authentication. Authentication
requires
the user to provide a set of credentials that
uniquely identify him. These credentials
are commonly a name and password but could be a physical token, such
as a key card, or a biological attribute, such as a thumbprint. The
computer
system consults an authority to determine if the
supplied credentials represent a known user and whether that user
should have access to the system. During operation, the system relies
on the user's authenticated identity when
performing
authorization—the process of determining
what actions and resources a user has authority to access. A
person's authority is expressed in terms of
roles. A role is
a logical
categorization that grants members of the role specific permissions.
To use an example with which you should be familiar, the Windows NT,
Windows 2000, and Windows XP user account systems provide a form of
RBS. Each user authenticates with Windows by providing a username and
password that must match a predefined user account; to the Windows
operating system, the user account represents the
user's identity. The Windows groups that the user
account is a member of represent the user's roles
and determine the resources and operations to which the user has
access.
The most common types of roles mirror the jobs and activities we
perform in everyday life, such as teller, manager, or administrator,
and grant their members the authority to perform the actions and
access the resources that they need to carry out their daily duties.
However, roles are an abstract concept that you can use to represent
any kind of grouping to which you want to assign a set of permissions
(for example, members of a certain project that need access to a
special color printer).
1. .NET Role-Based Security Explained
.NET provides a general-purpose RBS abstraction that you can use in
conjunction with a variety of authentication and authorization
mechanisms. In .NET RBS, an identity represents
the user on whose behalf code is running. Normally, this is the
currently logged-on Windows user, but this is not always the case. If
your application authenticates users against an authority other than
the Windows account system, then the identity may be different to the
currently logged-on Windows user.
A principal encapsulates an identity and
the
roles to which the identity belongs; we illustrate this relationship
in Figure 1. If the identity represents a Windows
user account, the roles will identify the Windows groups to which the
user belongs. Because a principal encapsulates both the identity and
roles of a user, it is the primary reference point on which the .NET
runtime bases any role-based security decisions.
|
.NET role-based security is independent of the role-based security
mechanism provided by COM+.
|
|
2. Comparing .NET Role-Based Security and Windows Security
.NET RBS makes it easy to integrate with the Windows user accounts
system, but .NET RBS is not just an extension of Windows user
security into the .NET runtime. .NET RBS and the Windows user account
system are completely independent security mechanisms that operate
concurrently and serve different purposes.
Windows security protects the integrity of the entire system by
controlling user access to important operating system operations and
resources. Every Windows process and thread has an associated
access token that represents the user on
whose behalf the process or thread is running. The access token is an
operating system object that contains information about the
permissions and privileges of the user it represents, and the groups
to which the user belongs. Before Windows allows code to perform a
protected operation or access a protected resource, it evaluates the
thread's access token to ensure that it contains the
permission necessary to perform the operation. Windows enforces
security regardless of whether an action is initiated by a managed
.NET application or native code.
.NET RBS operates at the application level, providing a convenient
mechanism through which you can control access to functionality based
on the user's identity and roles. For example, you
may only allow users who are members of certain roles to call an
important method or you may make different menu items visible
depending on the roles of the current user. Each thread running .NET
code has a principal associated with it; the principal serves a
similar purpose to the Windows access token, allowing .NET to
determine if the user on whose behalf a thread is running is a member
of a specified role. Although it is common for both the principal and
access token of a thread to represent the same user, they are
independent objects and there is no fixed relationship between the
two. The use of .NET RBS is entirely optional; you are responsible
for deciding what is protected by .NET RBS, and you must express
these requirements in your code.
|
A .NET application can change the Windows access token of the current
operating system thread in order to impersonate another Windows
user |
