This article is based on ASP.NET 3.5 and VB.NET. Application Security has an important role in information management. Distributing the right information to the right people at the right time is the key of information management. In addition to making sure that the information reaches the right people, it also has to make sure that it should never reach unauthorized hands. Here is the role of information security. Providing application security is an important aspect of ensuring information security. The main purpose of application security is to protect the application and data from unauthorized access.
The purpose of this case study is to explain how to implement application security for ASP.NET web applications using ‘Integrated Windows Authentication’.
2. How to Secure Web Applications
Authentication and Authorization are the two factors of ensuring application security.
Authentication is the process of deciding who can access the application. User name and Password is the most common mechanism for Authentication.
Authorization is the process of deciding what an authenticated user can do with the application. An application may provide different functionalities for the access of different users. Access to various functionalities can be restricted based on the type of the user. This is called role based authorization. For example, an ‘administrator’ will have a lot more access rights than a ‘guest user’.
3. What is ‘Integrated Windows Authentication’?
In integrated windows authentication, the application makes use of the credentials of Windows users. IIS supplies the client- credentials to ASP.NET. Based on the application specific security architecture, the application can validate these credentials against the ‘access rights information’ configured for the application. Only if the validation is successful, the user is allowed to access the application.
3.1. Single Sign on
This technology allows the user to use the same credentials for accessing multiple applications. Once the user has successfully logged on to the operating system, other applications can make use of these credentials from the operating system. ‘Single Sign on’ can be implemented in ASP.NET applications by using ‘Integrated Windows Authentication’. Once a user has logged on to Windows operating system, he/she is able to freely access the application as if no more sign on is required (provided the user has been given access rights to the application). However, during the application startup, it silently checks for the credentials of the user against the ‘access rights information’ configured for the application. Only if the credentials are matching, the user is allowed to access the application.
4. Where is ‘Windows Authentication’ Applicable?
Since ‘Windows Authentication’ uses the credentials of Windows users, it can be used only for an intranet application. In an intra-net application, the administrator has full control over the network users. The application can be designed in such a way that it can display all the ‘Active Directory’ users so that the administrator of the application can configure the users authenticated for the application. Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain, and where administrators can ensure that every user has Microsoft Internet Explorer, version 2.0 or later.
WindowsAuthenticationModule’ provider, it is possible to provide web application security with a minimum of ASP.NET coding. The provider module constructs a
WindowsIdentity object. The default implementation constructs a
WindowsPrincipal object and attaches it to the application context. The
WindowsPrincipal object maps identities to Windows groups. Using the authorization tag of web.config file, it is possible to restrict users/groups from accessing various application folders.
It is also possible to implement a custom Windows authorization scheme. For this purpose, you can use ‘
WindowsAuthentication_OnAuthenticate’ event handler to create a
WindowsPrincipal or a GenericPrincipal object from a
WindowsIdentity object. You can then use one of the new objects to implement your own custom authentication schemes.
6. How is ‘Windows Authentication’ Working - A Case Study
Here is a case study showing how to implement Windows Authentication and Role based security in ASP.NET. It starts with a detailed problem definition followed by the solution architecture. It also gives step by step details of solution-implementation.
6.1. Problem Definition
Here is a web application for preparing Business Plans for a Multinational Company ABC. All the users are registered in the Active Directory of its intranet domain and need to access the application from this intranet. The application offers the following functionality to users:
- Prepare master data
- Create Business Plans
- Approve or reject Plans
- Prepare reports
Access for the Master Data (MD) users should be strictly restricted to ‘Prepare master data function’ where as Central Support Team (CST) can access all the functionality except ‘Approve or Reject Plans’. The Area Managers (AM) can access only ‘Approve or Reject Plans’ and ‘Prepare Reports’. Based on this requirement, we need to implement role based, single sign on security for this application.
6.2. Solution Architecture
We can use the ‘Windows Authentication’ to provide role-based, single sign on security to this application. In order to enable the Windows Authentication, we need to configure the IIS directory settings to ‘Integrated Windows Authentication’. This will enable the IIS to get the client credentials and pass it on to the ASP.NET application.
In this case study, we use custom Windows authorization. Using the ‘
WindowsAuthentication_OnAuthenticate’ event handler, we create a GenericPrincipal object from a
WindowsIdentity object. The reasons for choosing a custom authorization are listed below:
- The application roles are not related to windows groups, and
- The application files are not physically grouped based on the roles
The application also requires a few additional ‘administrative’ screens to manage the user-roles and authentication information. The user screen should display all the user names from ‘Active Directory’, so that the administrator can select only those users who need to access the application. This screen should also allow the admin to assign any of the following three roles to the user – ‘MD’, ‘CST’ or ‘AM’. This information is stored in a separate ‘Users’ table in the Database.
On session startup, the application has to check the client credentials sent by IIS against that stored in the Database. If it does not find a match, it has to report an attempt for unauthorized access and exit the application. If the client credentials match, then it constructs a client cookie which stores the user credential and the role information. For subsequent requests, instead of hitting the Database for validating the client-credentials, the application makes use of this client-cookie. In order to secure the client cookie, using the ‘user identity’ and ‘role’ information, we create a ‘
FormsAuthenticationTicket’. This ‘
FormsAuthenticationTicket’ is then passed as the parameter to the ‘
Encrypt’ method of the ‘
FormsAuthentication’ class to get an encrypted string of the ‘
FormsAuthenticationTicket’. This string is then stored in a client cookie.
On each request, if the user is authenticated, the application creates a security ‘
Principal’ object and stores the user-role information in it. Then this ‘
Principal’ object is put in
HttpContext.Current.User. On each ‘
Page_Load’ event, the application can access the ‘
Principal’ object from
HttpContext.Current.User and validate whether the user role is authorized to access the page.
6.3. Implementation Details
6.3.1. Configure the IIS security settings for the application
In the IIS security settings for the application, check the ‘Integrated Windows Authentication’ and uncheck all other options.
6.3.2. Web.Config entries for Windows Authentication
In Web.config, under the
System.Web tag, put the following entries:
< allow users ="*" />
If you want to make the sub processes (e.g.: Web Services) also use the same credentials of the main thread, use the following entry.
6.3.3. User management screens
As already stated in the ‘Solution Architecture’ section, the application should have screens for ‘user management’. Using this screen, the administrator can map AD-user names against application roles. In this application, the user-roles are predefined hard-coded values - ‘MD’, ‘CST’ and ‘AM’. The application-administrator can either directly type in the AD-user name or the application may display all the AD-user names so that the administrator can select the user names. In order to display the AD-usernames, the application can query the Windows active directory using the .NET base class –
6.3.4. Security Principal object
Create a class which implements
Public Class myAppPrincipal
Private m_identity As IIdentity
Private m_roles As String()
Private m_userId As String
Public Sub New(ByVal identity As IIdentity, ByVal roles As String())
m_identity = identity
m_userId = identity.Name
Public Property UserId() As String
Set(ByVal value As String)
m_userId = value
Public ReadOnly Property Identity() As System.Security.Principal.IIdentity _
Public Function IsInRole(ByVal role As String) As Boolean _
Return IIf(Array.BinarySearch(m_roles, role) >= 0, True, False)
6.3.5. Checking Authentication and identifying roles
The most important part of implementing security is to ensure that on each request, the application verifies the authentication and resolves the user role. For this purpose, we are making use of the following global application level events.
WindowsAuthentication_OnAuthenticate(Object source, WindowsAuthenticationEventArgs e)
Application_AuthenticateRequest(Object sender, EventArgs e)
These events are raised automatically on each request.
WindowsAuthentication_OnAuthenticate” is raised first. In the corresponding method, we implement the following logic.
- Check whether ‘
authenticationCookie’ for the application exists. If so, return from the method. If it does not exist, continue with next steps.
- Extract the AD-user name sent by IIS. It is available in the event argument as “
- Query the Database for application-roles against this user-name.
- Create a ‘
FormsAuthentication ticket’ and embed a string of user roles in it.
- Create a new ‘
applicationauthenticationCookie’ and store the encrypted ‘
FormsAuthentication ticket’ in it.
Inside the method for “
Application_AuthenticateRequest” event, do the following.
- Read the ‘
applicationauthenticationCookie’ and re-create the ‘
- Read the user roles from the ‘
FormsAuthentication ticket’ and create an object of the ‘principal object’ which contains these user-roles.
- Store this ‘principal object’ in ‘
The following code shows the implementation of these tasks:
Public Sub WindowsAuthentication_OnAuthenticate(ByVal sender As Object, _
ByVal args As WindowsAuthenticationEventArgs)
If (Not Request.Cookies.Get("authCookie") Is Nothing) Then
Dim strUserIdentity As String
Dim strUserRoles As String
Dim formsAuthTicket As FormsAuthenticationTicket
Dim httpCook As HttpCookie
Dim strEncryptedTicket As String
strUserIdentity = args.Identity.Name
strUserRoles = GetUserRoles(strUserIdentity)formsAuthTicket = New FormsAuthenticationTicket(1, strUserIdentity, DateTime.Now, _
DateTime.Now.AddMinutes(60), False, strUserRoles)
strEncryptedTicket = FormsAuthentication.Encrypt(formsAuthTicket)
httpCook = New HttpCookie("authCookie", strEncryptedTicket)
Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As EventArgs)
Dim formsAuthTicket As FormsAuthenticationTicket
Dim httpCook As HttpCookie
Dim objGenericIdentity As GenericIdentity
Dim objMyAppPrincipal As myAppPrincipal
Dim strRoles As String()
httpCook = Context.Request.Cookies.Get("authCookie")
formsAuthTicket = FormsAuthentication.Decrypt(httpCook.Value)
objGenericIdentity = New GenericIdentity(formsAuthTicket.Name)
strRoles = formsAuthTicket.UserData.Split("|")
objMyAppPrincipal = New myAppPrincipal(objGenericIdentity, strRoles)
HttpContext.Current.User = objMyAppPrincipal
6.3.6. Checking role based Authorization
Page_Load’ of each web page, check whether the user current-role available in ‘
HttpContext.Current.User’ is allowed to access the page. If not, then redirect to a common page showing the message ‘You are not authorized to view this page’.
- Providing application security is an important aspect of ensuring information security.
- Authentication helps to verify that the user is, in fact, who the user claims to be. The application obtains credentials (various forms of identification, such as name and password) from a user and validates those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. Authorization Limits access rights by granting or denying specific permissions to an authenticated identity.
- ASP.NET uses Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication. When IIS authentication is complete, ASP.NET uses the authenticated identity to authorize access.
- In ASP.NET, Windows authentication can be used along with either ‘windows role’ based authorization or ‘custom authorization’. In ‘windows role’ based authorization, access to application folder for windows users/groups, is granted/denied as per the setting in web.config. Whereas in ‘custom authorization’, this logic is implemented programmatically.
||Internet Information Services
||Central Support Team