Professional ASP.NET Security - Jeff Ferguson
.pdf
Implementing Authorization
In our day-to-day work lives, we are normally required to work within certain rules and regulations. In order to do certain types of things, we need to be authorized to do so. For instance, as a bank customer, we will be authorized to speak to a teller over a counter, but we will not be authorized to enter the teller's office: a locked door is put in place to prevent this.
In an application environment, it is we, the application developers, who have to put in place mechanism in order to grant or deny authorization to particular users. For instance, any bank loan application will go through a series of stages, and at each stage only certain authorized persons will be allowed to perform the necessary actions: only Bank Managers might be allowed to approve a loan. Anyone else trying to access the loan approval functionality should be denied access. We IT Professionals need to convert these real-life scenarios into systems and need to implement such authorization mechanisms.
In the ASP.NET web application environment, authorization means granting access to resources. Such resources include file systems, databases, Message Queues, ASPX pages, and so on. The process of authorization basically involves the creation of users or groups, defining permissions for them, and mapping users with the resources. At run time, the .NET Framework grants or denies authorization. This can be done in several ways, including file authorization, URL authorization, and any number of different types of custom authorization.
In order to understand how ASP.NET Framework controls access to restricted resources we need to understand the following in detail:
Q How roles are defined
Q Configuration of web. config
Q File authorization
G URL authorization
Q Checking for Privileges at run time
Q Custom Authorization
Q Configuring the web. conf ig for Custom Authorization
Q Handling failed authorization with custom error messages
Roles
A role that a person has within an organization is associated with having certain responsibilities. Every organization will contain sets of persons who have to perform certain roles, and with these roles will come certain privileges, in particular, access to certain resources or the authority to execute certain decisions. When we group people in this way, it becomes easier for an administrator to assign privileges to certain sets of people.
Why bother creating groups when you can assign permissions to the users? Imagine an enterprise network with thousands of users. If you were to define permissions for each individual user, it would become a tiring job. Instead, if you group them under a certain category and define permissions, things are much easier and more manageable.
The concept of a groups, with which we are familiar in Windows, corresponds with the concept of a role in the .NET Framework. However, it is always worth noting that in the .NET Framework, the users and roles need not be the same as Windows Users or Windows Groups. .NET provides the flexibility to use either Windows Users or Groups or Application-defined Users or Roles.
Once users and roles have been defined, we can implement permissions based on these roles. In the .NET world, this is called Role-Based Security.
In the following section, we will investigate in detail the way in which Role-Based Security is implemented in the .NET Framework. Although most of this will be familiar from earlier in the book, it will be useful to revise some of the important concepts here.
Principal and Identity
The most important thing to grasp about Role-Based Security is how .NET grants permissions to users and roles. In order to understand this, we need to understand the roles of the Identity and the Principal. Let's very briefly remind ourselves how these work.
Identity
Identity, as the name suggests, represents a user's identity. Whenever you log on to your computer, you are asked to provide a user ID and password. The user ID represents your identity. In .NET, the identity of a user could be represented using one of the following four identity objects, depending on the type of authentication used:
284
Implementing Authorization
Q Windowsldentity
Q Formsldentity
Q Passportldentity
Q Genericldentity
When you log on to a .NET application with a Windows User Account, the underlying Identity object would be a Windowsldentity object; if an application is configured to use Passport Authentication, then the underlying Identity object would be Passportldentity; and so on. These different identity objects all implement the I Identity interface. This Ildentity interface is a part of the System. Security. Principal namespace.
In virtue of the Identity object, an application may always find the user attached to the current thread, irrespective of the type of underlying Identity object. Prior to the advent of .NET, we would generally have to implement our own system for identifying users within an application, but with .NET, this is provided by built in functionality. Even if our application uses a custom authorization mechanism, we can represent users using the Genericldentity object. This provides a uniform was of representing individual users.
A Genericldentity object may be implemented in the following way:
private Ildentity objgenricidentity ; objgenricidentity = new Genericldentity("WroxUser");
Principal
In Windows 2000, we have the option of denying permissions to a folder for a specific group. When a user attempts to access that folder, a 'permission denied' message is displayed. The Windows user is mapped to a particular group, and credentials are verified using this group.
In .NET, the Principal is a combination of a users and the groups the user belongs to. That is, it represents the both the Identity and the roles.
The .NET Framework defines two Principal objects: WindowsPrincipal and Genericprincipal. While WindowsPrincipal object represents the Windowsldentity and associated roles, Genericprincipal provides the flexibility to build custom Principal objects.
Both WindowsPrincipal and Genericprincipal implement the IPrincipal interface (System. Security. Principal namespace). The IPrincipal interface provides the following methods and properties to get the Identity object and to check whether the user belongs to the role or not :
Q |
Ildentity Identity |
{get;} |
- to get the underlying identity object |
|
Q |
IsInRole (string role) ; |
- to determine whether the user belongs to a certain role |
||
Now that we have understood the concept of Identity, Principal and role, lets take a look at how the .NET Framework uses these objects to implement authorization.
285
Role-Based Security
The .NET Framework provides flexibility in combining the users (identity) with roles, and defining permissions for these principals.
When permissions to a resource are defined for a role, the .NET Framework requires the users to have these permissions before accessing the resources. We might want to grant access for certain users to write to a file, and deny access to certain users to read or write from the same file. We might want certain users to read messages from a queue, but not write to the queue. Although our precise requirements will differ from application to application, the way in which such authorization is implemented is the same.
In general, the authorization requirements of an application may be as follows:
Q Users should have proper credentials to access a resource
Q Certain users need to be denied access to particular resources
G Only certain users should be allowed to access particular resources
In order to implement such security mechanisms in an application, the .NET Framework provides a set of built-in Permission objects, which enforce users having appropriate permissions to access certain resources.
We will take a couple permission objects - FilelOPermission and Principal-Permission - that we can take as examples to explore how the .NET Framework implements Role-Based Security.
These built-in permission objects protect the specified resource. For example, FilelOPermission will ensure that only the authorized users are allowed to access a file. That is, FilelOPermission will map the current user's credentials with the permissions set for the file at the operating system level. Similarly, the MessageQueuePermission object ensures the user's credentials match with the permissions set at MSMQ. In these two cases the Permission objects validate the credentials with the security settings at the operating system level.
FilelOPermission objects require users to be Windows users, or an ASP.NET process to be running under a particular identity, and grant permission to read or write depending on the permissions defined for the folder or file in the file system. That is, the FilelOPermission object validates the Principal in the context of the permissions defined within the file system.
For example, in an ASP.NET application, we may want to write to a file on the click of a button. In this case, the file should have the necessary access permissions set, and the user logged on to the application should be granted necessary permissions.
Sometimes, we might want to deny access to a specific folder, such as C: \WinNt. We can do so by denying permission on the FilelOPermission object at run time. The following code written above the corresponding method (button_click) denies access to the WinNt folder for any user:
[FilelOPermissionAttribute(SecurityAction.Deny, |
A11="C:\\winnt")] Note |
that FilelOPermissionAttribute is a declarative way of demanding permissions.
286
Implementing Authorization
The SecurityAction enumeration defines what type of SecurityAction is being performed. One may want to deny access to a resource or one may want to demand that the caller in the context has sufficient privileges. The SecurityAction enumeration contains values that can be used to request a specific action at compile time, at class level, method level, or assembly level.
The other permission object, PrincipalPermission, ensures that the caller's context has the requested Principal associated with it. The PrincipalPermission object is used to validate the caller's identity and role with the PrincipalPermission object's identity and role.
The following line of code ensures that access to a particular method is only granted to a user with the username of 'bob'.
[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "localhost\\bob" )]
When this line of code is placed above the method declaration of any method, the .NET CLR ensures that the caller in the context has the requested credentials. This gives us great flexibility in implementing role-based security not only at resource level but also at application level.
Note that in cases where we use Windows authentication, the PrincipalPermission object contains the WindowsPrincipal: that is, it contains the Windowsldentity, AuthenticationType, and the role (Windows Group). A detailed explanation of PrincipalPermission is defined later in this chapter.
Now that we have looked a little at Authorization and how .NET role-based security is implemented, let's get to grips with how this works within the ASP.NET architecture. We'll look at both how to configure ASP.NET for authorization, and at a couple of authorization schemes provided with ASP.NET.
ASP.NET Authorization
In any web-based application, authentication and authorization are the two main security checks that should be in place. Once a user is authenticated to access an application, the application should determine what functionality is to be made available to that user. In ASP.NET, the process of determining what functionality is made available starts from what ASPX pages the user is allowed to access. The rule of thumb here is that the application should determine the mapping between users and the resources. For instance, certain applications, such as a loan processing application, would make the loan approval screen accessible only to managers. One may come across different combinations of such situations. While the implementation of such authorization schemes might vary, depending on the application, ASP.NET provides some generic types of solutions, such as File Authorization, URL Authorization, and Custom Authorization. We will explore in detail each of these authorization types, and how they will help in securing an application.
File Authorization
Most of us are aware of the concept of file security in NT/Windows 2000. If the file system is configured as NTFS, then you can set permissions not only at folder level, but also at file level. If you deny permissions to a specific file or folder for certain group, any user who belongs to that group will be denied access to that file or folder. Here the Access Control List (ACL) controls access to the protected resources for the users or groups.
OQT
The FileAuthorizationModule class uses this underlying mechanism to control access to ASPX pages. The access privileges are set by the Administrator for the Windows Users and Groups: the administrator will generally grant permissions to files or folders for a specific user or a group by the simple technique of right-clicking the file or folder, clicking on properties, and then clicking on Security. When a Windows user tries to access a protected resource through an ASP.NET application, the user's credentials are checked through the FileAuthorizationModule. The FileAuthorizationModule will deny access if the user doesn't have sufficient privileges.
File Authorization will work only in conjunction with Windows Authentication. If your ASP.NET authentication is set to Passport or Custom Authentication, File Authorization will not come into play.
Implementing File Authorization
To see how to use File Authorization in some more detail, let's create a web application and a few Windows users, and walk through the scenario of granting permissions. First, create a new C# ASP.NET Web Application.
Let's name this project FileAuthorization, and place it under a directory called WroxSample. Name the form Index.aspx.
Place the following code under the <f orm> tag:
<a href ="AuthorizedFile.aspx"> Click Here for AuthorizedFile </a> <br>
<a href ="UnAuthorizedFile.aspx"> Click Here for UnAuthorizedFile </a>
Now add two new web forms, one called AuthorizedFile.aspx, the other called
UnAuthorizedFile.aspx.
Under the <Form> tag in AuthorizedFile. aspx, enter the following:
<h2> Congrats!!! You are Authorized to View this Sample </h2>
And under the <Form> tag in UnAuthorizedFile. aspx, enter the following:
<h2> You are Unauthorized to View this Sample </h2>
Now compile the solution and view this sample in the browser.
We have defined a very simple sample ASP.NET web application without any authorization criteria set. Now, when we click either of these URLs, we should see the appropriate messages.
Let's now create the following users with different sets of privileges and try this example. We can create a new user within the Computer Management console:
288
Log in as WroxAuthor. Now when you try to access the UnAuthorizedFile. aspx you will be denied access.
Configuring web.config for Windows Authentication
File authorization will work only if the authentication is set for Windows. If you are using any other type of authentication, FileAuthorization will fail. By default, when you create a web application, your web.config is set for Windows Authentication. The following line of code in the web. conf ig under <System.Web> defines what sort of authentication is being used. In this case it is Windows:
authentication mode= "Windows" />
Configuring for ASP.NET Impersonation
Isn't there any other way to access the protected resource using the identity of another user when the application is configured under Windows Authentication and File Authorization? Well, yes there is.
Suppose that WroxUser and WroxEditor are given full control of a resource. When WroxAuthor tries to access this resource, access will only be granted as long as the credentials of WroxUser or WroxEditor are supplied. The ASP.NET application will prompt the user for a UserlD and password. As long as the correct credentials are provided, access to the page will be granted. This is impersonation.
If we don't want to allow impersonation, we can configure our application to allow or deny impersonating users. By default, impersonation is disabled. If we need to enable impersonation, we need to add the following line into the web.config under <System.Web>.
<identity impersonate="true" />
There could be situations where you can't rely on the operating system to control access to your application, or in which you don't want to assign permissions to files for every new user or role. Imagine an enterprise application with thousands of pages and thousands of users. Assigning permissions for every single user or group to all those pages or folders would become impractical. Further, if any new user or group is added to the system, then the system administrator will have to define permissions for all the web pages for this new user.
Under such circumstances, we need a different mechanism to control access to pages. It would be easier if we could control access from our ASP.NET application, without having to writing any code to explicitly perform authorization checks. URL Authorization provides one such mechanism, with which we can control access to the pages in a web application. In the following section, we will explore how to use URL Authorization to authorize users to access certain resources.
URL Authorization
A web application should be flexible enough to grant permissions to access pages without having to reconfigure the operating system. That is, an ASP.NET application should be capable of granting or denying access to ASPX pages to users or roles. The basic requirement is that the ASP.NET application should:
Q Allow specific Users or Roles access to particular Resources Q Deny specific Users or Roles access to particular Resources
290
Implementing Authorization
Jn order to achieve an authorization scheme like the one we put together earlier, there should be a process in place to define the users or roles, and map the users with particular URLs. Further, there has to be functionality to ensure that the caller's credentials match the defined user and URL mapping. Web. conf ig and the URLAuthorizationModule perform these two functions.
While the configuration file, web. conf ig, enables us to define the application users and roles, the URLAuthorizationModule (the module that implements IHttpModule interface) ensures that the application user's credentials match the specified mapping. In the following section we explain how the web. conf ig can be configured for URL Authorization.
Authorization Section in web.conf ig
The following code is used in the web. conf ig file to define users, roles, and types of actions.
<authorization>
<allow users="comma-separated list of users" roles="comma-separated list of roles" verbs="comma-separated list of verbs" />
<deny users="comma-separated list of users" roles="comma-separated list of roles" verbs="comma-separated list of verbs" />
</authorization>
We may choose to allow or deny access to particular users or roles. Moreover, we might specify what kinds of actions particular users or roles may perform: this is done through specification of an appropriate verb.
Q allow - defines the users and roles that are allowed to access the resource. We can also control what sort of action is being done on the web page. For example, an HTTP POST or HTTP GET.
Q deny - defines the users and roles who are denied access to a resource. We can also control what sort of action is being done on the web page. For example, an HTTP POST or HTTP GET.
Q verbs - GET or PUT. Every HTTP request is accompanied by an operation: a GET or PUT. We can define permissions for a URL to allow or deny GET, PUT, or both.
For example, we could configure our previous application to use URL Authorization.
Before we proceed further with this example, let's assign Full Control to everyone for the file UnAuthorizedFile. aspx. Now we can edit the web. conf ig to allow access to WroxUser and WroxEditor, and deny access to WroxAuthor, to the sample ASP.NET application. In the web. conf ig file, we need to add the following code:
<authorization> |
|
<allow users |
= "LOCALHOST\WroxUser , LOCALHOST\WroxEditor"/> |
<deny users |
= |
" ? " / > </authorization
To define permissions for all users or roles use * instead of specific user or role. ?
refers to anonymous users.
We have restricted access to anonymous users by using <deny users = " ? " /> in the web. conf ig file.
We must also configure the IIS Virtual Directory permissions so that anonymous users are not allowed. This is done under the Directory Security tab of the security properties dialog for the appropriate directory.
| Documents DfecSorjt Security | HTTP Headers] Custom
EEFQI us access and authentication control
Enable anonymous access and edit the authentication methods for tNs resource
) |
Anonymous access '"' |
No user name/password required to access this lesouice
Account used for anonyrrious access
access is disabled, of access is restricted using NTFS access control 1st*
Select a default domain
Integrated',
Configuring Authorization for a Specific File or Folder
The above configuration scheme is applicable for the entire application. Under circumstances where we want to define a separate set of access to folders or files, we can use a <location> tag in the web.conf ig file. We can use the <location> tag where we can specify the path or file, and the corresponding permissions. In our case, to define authorization, we need to add:
<location path="File |
or Folder"> |
|
<system.web> |
|
|
<authorization> |
|
|
<allow users, |
roles, |
verb/> |
<deny users, |
roles, |
verb/> |
</authorization> </system.web> </location>
For example if you want to deny access to UnAuthorizedFile.aspx for the user WroxUser, then you may put the following line in the web. conf ig after the <system. web/>:
<location path="UnAuthorizedFile.aspx"> <system.web>
<authorization>
<deny users = "LOCALHOSTXWroxUser"/> </authorization>
</sys tern.web> </location>
292