This article can also be found in the Premium Editorial Download "Information Security magazine: Identity crisis solved: Tips from a top identity management expert."
Download it now to read this article plus other related content.
The following are the basic methods that are used in the .NET framework:
Role (xx) to create a new role
Add (xx) to add a new role to the database
Update (xx) to update an existing role
The following code will assign a user to a new role:
SiteRole newUser =
new SiteRole( Context.User.Identity.Name );
Context.User = newUser;
Who--Or What--Are You?
In general, development platforms have provided rigid but strong access control designs, or flexible but potentially insecure access controls. .NET's access control architecture provides the flexibility to give users and applications the permissions they need--and nothing more. It does this in two basic ways:
Role-based access control addresses the gap between highly secure, rigid mandatory access control (MAC) architectures and flexible, insecure discretionary access control (DAC) platforms.
MAC is typical of older mainframe and some highly classified government systems. MAC is secure because the operating system controls all access between subjects and objects; every user is assigned a clearance level (e.g., "Secret"), and every object or file is assigned a classification level (e.g., "Top Secret"). This provides excellent control, but requires a lot of effort to implement and maintain. For that reason, it's not seen much anymore.
Most modern operating systems are based on DAC, in which an admin decides on permissions and assigns them to objects accordingly. DAC allows tremendous flexibility to control who has access to what, but it can be a security nightmare. While an organization should have a policy dictating that proper approvals are required before authorizing access, there's no assurance that it's done--or done properly. Moreover, since access permissions are assigned to the users, the admin has to make sure to revoke those privileges if they are transferred or terminated, in addition to assigning permissions to their replacements.
.NET overcomes this problem by allowing developers to assign built-in roles in the application to make sure the proper granularity of control is provided (see Figure 1). Since security needs to be built into the design from the beginning, this allows security to be part of the architecture and built within the code. Admins responsible for the application can determine who is assigned to a certain role; but it's the role, not the individual, that is granted permissions, strengthening security and tightening control.
Evidence-based access control builds an additional layer of security that attaches permissions to the code itself, limiting how it executes. In a Web environment, small mobile code has to be flexible enough to interact with other code, yet still be secure. One danger is that untrusted code from the Internet could be used to access other applications on the system, allowing it to compromise the system or get to privileged data.
With .NET, the code, just like the user, has security assigned to it, defining when and where it can run. When a piece of mobile code is downloaded, it must have the proper permission to run on the system. These controls check the code for evidence defined by security policy (such as a digital signature), validate it and enforce the restrictions under which it can operate.
This was first published in May 2006