Authorization in ASP.NET

There are two closely interlinked concepts at the heart of security for distributed applications - authentication and authorization. Authentication is the process of obtaining some sort of credentials from the users and using those credentials to verify the user's identity. Authorization is the process of allowing an authenticated user access to resources. Authentication is always precedes to Authorization; even if your application lets anonymous users connect and use the application, it still authenticates them as being anonymous.

web.config determines the users who will be authorized to or denied from the website. The default value is <alow users="*"/> which allows everyone to access the pages in the application. The value <deny users="?" /> means to deny any anonymous (unauthenticated) user trying to access the website. However, this value can be changed.

E.g., <deny users="john", "smith", "Ahmed" /> means to deny the users: john, smith and Ahmed from accessing this website - it is a black list- or you can say <deny users="*" /> <allow users="john", "smith", "Ahmed" /> which means, deny all users except john, smith, and Ahmed.

<!-- AUTHORIZATION
This section sets the authorization policies
of the application. You can allow or deny access
to application resources by user or role.
Wildcards: "*" mean everyone, "?" means anonymous
(unauthenticated) users.
-->

<authorization>
<deny users="?" /> <!-- Allow all users -->
<!-- <allow users="[comma separated list of users]"
roles="[comma separated list of roles]"/>
<deny users="[comma separated list of users]"

roles="[comma separated list of roles]"/>
-->

</authorization>

Roles
In some business websites, multiple employees would need access to a system in order to do specific tasks. However, each employee would have a specific role, and specific operations to do, according to the nature of his/her job or security level. E.g., an HR manager might not allowed to view the data of the seals department.

ASP.NET provides the concept of roles that gives each role a different view on specific pages.

<location path="HRpages">
<system.web>
<authorization>
<allow roles="HR" />
<deny users="*" />
</authorization>
</system.web>
</location>

<location path="salesPages">
<system.web>
<authorization>
<allow roles="sales" />
<deny users="*" />
</authorization>
</system.web>
</location>

location here means the folder name which holds the .aspx for some specific role. As the example shows, <location path="HRpages"> means that all .aspx files under the HRpages folder are protected. <allow roles="HR" /><deny users="*" /> mean deny every one from accessing pages under HRpages except those having the HR role.

Impersonation
After your application has authenticated users, you can proceed to authorize their access to resources. But there is a question to answer first: Just who is the user to whom your are grating access? It turns out that there are different answers to that question, depending on whether you implement impersonation. Impersonation is a technique that allows the ASP.NET process to act as the authenticated user, or as an arbitrary specified user.

ASP.NET impersonation is controlled by entries in the applications web.config file. The default setting is "no impersonation". You can explicitly specify that ASP.NET shouldn't use impersonation by including the following code in the file

<identity impersonate="false"/>

With this setting ASP.NET does not perform impersonation. It means that ASP.NET will runs with its own privileges. By default ASP.NET runs as an unprivileged account named ASPNET. You can change this by making a setting in the processModel section of the machine.config file. When you make this setting, it automatically applies to every site on the server. To user a high-privileged system account instead of a low-privileged, set the userName attribute of the processModel element to SYSTEM. Using this setting is a definite security risk, as it elevates the privileges of the ASP.NET process to a point where it can do bad things to the operating system.

When you disable impersonation, all the request will run in the context of the account running ASP.NET: either the ASPNET account or the system account. This is true when you are using anonymous access or authenticating users in some fashion. After the user has been authenticated, ASP.NET uses it own identity to request access to resources.The second possible setting is to turn on impersonation.

<identity impersonate ="true"/>

In this case, ASP.NET takes on the identity IIS passes to it. If you are allowing anonymous access in IIS, this means ASP.NET will impersonate the IUSR_ComputerName account that IIS itself uses. If you aren't allowing anonymous access,ASP.NET will take on the credentials of the authenticated user and make requests for resources as if it were that user. Thus by turning impersonation on and using a non-anonymous method of authentication in IIS, you can let users log on and use their identities within your ASP.NET application.

Finally, you can specify a particular identity to use for all authenticated requests

<identity impersonate="true" username="DOMAIN\username" password= "password"/>

With this setting, all the requests are made as the specified user (Assuming the password it correct in the configuration file). So, for example you could designate a user for a single application, and use that user's identity every time someone authenticates to the application. The drawback to this technique is that you must embed the user's password in the web.config file in plain text. Although ASP.NET won't allow anyone to download this file, this is still a security risk if anyone can get the file by other means.

Best practices
Now that you know what the choices are for ASP.NET authentication, here are some points that tell which to choose.
• If there is nothing sensitive about the application, stick with no authentication in ASP.NET and anonymous authentication in IIS. That lets anyone who can reach the host computer use the application.
• If you have to authenticate users, there are several choices. If all users have accounts on your network, use Windows authentication in ASP.net with one of the strong IIS authentication settings. If users don't have network accounts, own custom authentication scheme is preferred, means forms authorization.
• If different users must have different privileges, impersonation in ASP.net configuration files needs to be turn on.

posted by Vijay Kumar @ 11/01/2006 11:37:00 PM