Security Viewpoint: Impersonation and the Access Control List

**Security Viewpoint – May 2009
**See other Security Viewpoint columns

By John Steer, Security Architect, Microsoft Application Consulting & Engineering (ACE) Team

This article provides insight into impersonation and access control lists (ACLs) from a developer’s perspective. As part of the development of a Microsoft® .NET application, one feature you need to be thinking about is application security. Consideration needs to be given to security as a feature early in the development lifecycle, it is a foundational component that needs to be integrated from the ground up.

Depending on an application’s privacy and security requirements, there will be a need to safeguard sensitive data from access by an unauthorized application resource. An intrusion could come from a hacker attempting to compromise the system or from an inadvertent programming error introduced during the development of the impersonation security feature.

Examples of sensitive data include a database that contains restricted data elements, a text file that contains system parameters, or a registry entry that stores security credentials. These elements may contain personally identifiable information (PII) such as a social security number, online banking credentials, or other high-profile information that requires protection based upon company policy or legislative mandate.

Impersonation is the capability that permits an application to execute or use system resources as either the current identity (user account) or another designated identity to make the request. A common use of impersonation is an application that uses Internet Information Services (IIS) as its authentication service.

Impersonation allows your application code to execute under the context of a specific user credential. Microsoft ASP.NET will compile and load the application using the Windows® identity of the ASP.NET process. The use of impersonation and ACL’s provide the capability to segregate and protect application data that is stored in databases, local files and passed from other applications. Impersonation and ACL’s help facilitate this separation and provides an additional layer of application security.

Authentication enables the ability to restrict user access to the resources in a number of ways. Common authentication methods include user name and password, digital certificates, smart cards, and biometric identification. The information provided in the authentication process provides evidence or a claim by which the user offers a method to validate their identity.

Once user authentication is complete, the system must determine if the user has the proper authorization to access the requested resources. When using IIS in the Windows Server® 2003 and Windows Server® 2008 operating systems, you can have multiple application pools that specify a different identity. The use of the NTFS file system is required with the use of access control lists (ACLs). When you safeguard the application files with ACLs, it is easy to authorize users and prevent unauthorized users from accessing safeguarded files and data resources.

In the Windows operating systems and .NET, an ACL makes available a list of users that are allowed access to that resource. The ACL assigns permissions to the resource and provides a list of each user and security group that is authorized to access this item. The type of authorized access can include read, write, modify, and delete. So, for example, if the application needs to access a particular ASP.NET web page or text file, IIS will ask the operating system to verify the access requirements and whether the user has these permissions. The ACL will contain this information and will allow the operating system to make the proper decision. Once the user is authorized, access is allowed or disallowed to the requested resource.

Up to this point in the article, we have described impersonation, access control, and the general process that is followed to authorize an authenticated user’s access to a resource. In the next section, we will discuss how to use an ACL-based security model to provide resource access as part of a role-based security system.

Within a role-based application a user is assigned different roles based on the organization’s requirements and the job function that the user performs. When permissions are granted or taken away they can be done at a granular user level but as a best practice should be done at the group or role level.

A role is an application category of users that perform certain application functions. System resources can be assigned permissions (read, write, execute, delete) based upon the Windows group or application role.  This process will correlate the application role to a Windows security group. For example, if one user is part of a Windows sales group, his or her role might be ‘sales’; while another user might belong to a Windows developer group or the ‘developer’ role. At the operating system level, the sales group user would have an ACL entry that allowed access to the sales group but not to the developer group.

Within the application, any user assigned to the role of ‘sales’ would be able to access the sales information, and, subsequently, any other group would be denied access as currently defined by the ACL. Other users with roles such as ‘developer’ or ‘accountant’ would only have access only to the folders that include permissions within the ACL for the appropriate Windows group.

The permissions assigned to the ACL can be maintained through the use of the ACL editor, programmatically via the System.Security.AccessControl namespace, or from the command line with CACLS.  All the choices will enable the authorized user to maintain user roles along with the related permissions for the role and object.

The use of impersonation and ACLs provide the application the capability to secure resources and allow discretionary access based upon user role and specified permissions. The permission assignments are decoupled from the application and can easily be managed by the system administrator. This flexibility allows an application to be deployed under an initial security requirement and then modified at a later time as security requirements change.