ASP.NET Security Models

Planning Authentication and Authorization Strategies

RELATED: "Securing ASP.NET MVC," "The Definitive Guide to ASP.NET Security," and "ASP.NET Security Design Guidelines."

Selecting an appropriate authentication and authorization strategy can be one of the most important tasks in your application development process. And after selecting a strategy, it must be properly administered to prevent or alleviate many security risks. To gain an advantage from planning security specifications, you must perform the following steps:

  • Identify resources.
  • Specify user access to resources.
  • Consider identity flow.
  • Decide how to flow identity.
  • Select an authentication approach.
  • Select an authorization approach.

To narrow the focus a bit, let s explain these six steps.

Identify resources. All the resources used in a Web application can be identified in three main categories: Web Server Resources, such as Web pages, Web service, and static resources (files); Database Resources; and Network Resources, such as data stored in Active Directory.

Specify user access to resources. Users can access application resources with the authorization that an application gives them. The two kinds of authorization provided are role-based (access to resources specified by associated user roles), and resource-based (an application uses impersonation to allow access checking by Windows ACLs.

Consider identity flow. You must consider the original caller s identity across your application based on resource manager authorization and auditing requirements.

Decide how to flow identity. You can choose the following identities across your application:

  • Original Caller s Identity. Uses impersonation or delegation to access local or remote resources.
  • Process Identity. The default identity.
  • Service Account. The fixed-service account. Use it whenever the resource has interior access validation, such as database, active directory, etc.
  • Custom Identity. Applied when you want to use specific identities by IPrincipal and IIdentity belonging to your application-defined security.

Select an authentication approach. Authentication is the process of discovering and verifying the identity of a user by examining the user s credentials and then validating those credentials against some authority. There are two things that are vital when choosing an authentication approach. First is the user s browser type and whether they have a Windows account. Second is using impersonation/delegation in your application.

Select an authorization approach. Authorization is the process of determining whether a user is allowed to perform a requested action. Authorization occurs after authentication and uses information about a user s identity and roles to determine which resources that user can access. If you want to implement authorization in your code, you can choose one or both of two approaches: role-based and resource-based. In the role-based approach, users access each part of an application based on their roles. Role-based security happens within an application s front-end or back-end (or both). The resource-based approach authorizes users by Windows ACLs and access control mechanisms implemented by the operating system. The hierarchies of access check the process sequentially as the application impersonates the caller and leaves it to the operating system, in conjunction with specific resource managers (file system, database, etc.), to authorize.

The diagram in Figure 1 depicts the authentication and authorization priority in a .NET security scenario. The diagram in Figure 2 displays the .NET technologies and associated security strategies.

Figure 1: Authentication and authorization priority.


Figure 2: .NET technologies and security models.


ASP.NET Authentication Modes

ASP.NET works with IIS to provide the following security models: Windows authentication, Forms authentication, Passport authentication, and none (see Figure 3).


Figure 3: ASP.NET security services.


Windows authentication. Windows authentication is dependent on IIS authentication to create a user credential. IIS has five authentication mechanisms:

  • Basic authentication. This uses the user name and password to supply the user credential. Based on an unencrypted format, it is recommended to use SSL encryption for all pages (not only the login page).
  • Digest authentication. This was introduced after IIS 5.0. Similar to basic authentication, it instead uses hash credential transmission to provide a more secure aspect.
  • Integrated Windows authentication. This (Kerberos or NTLM, depending on the client or server configuration) uses a cryptographic exchange between an IE (not Netscape) Web browser or server and user to encrypt a user credential. It is applicable only for intranet scenarios.
  • Certificate authentication. This uses a client certificate (to identify a user credential), which must be installed on a user s computer to pass a client certificate to the Web server (after the Web server extracts it). Therefore, it is applicable only in intranet or extranet scenarios in which the client is configured and well known.
  • Anonymous authentication: If you don t want to use an authentication mechanism (or want to use a custom authentication), IIS implements anonymous authentication that uses only one Windows account for all users.

Forms authentication. An unauthenticated user gets redirected to the login page to enter their credential. The Web server then creates an authentication ticket for the user.

Passport authentication. ASP.NET uses the centralized authentication services of Microsoft Passport. This is covered in detail toward the end of this article.

None. This means that you don t want to use an authentication mechanism (or want to use a custom authentication). This mechanism doesn t have any special configuration to implement, so only the first three methods of authentication will be discussed in this article.


Windows Authentication

In this section we ll discuss Windows authentication configuration, and Windows authorization configuration and roles checking. Before using this strategy you need to know which mechanism is recommended when. First of all, Windows authentication (see Figure 4) can be applied only on intranet applications that use Windows users and groups. Also, based on security issues, you should use the central user registration of Windows. Use only Microsoft Internet Explorer and no proxy server or firewall should be used on the server.


Figure 4: Windows authentication.


Impersonation and delegation. A service or a component (usually somewhere within the logic of the business service layer) impersonates a client s identity (using operating system-level impersonation) before it accesses the next downstream service. If the next services are located on the same computer, then impersonation is required. If the next services are located on a remote computer, delegation is required.

This mechanism also can be used with or without impersonation (in the following circumstances). With impersonation:

  • Your application s users should have a Windows account authenticated by a server.
  • You need to use the original caller s security context for the middle and/or data tier to support per-user authorization.
  • You need to flow the original caller s security context to the downstream tiers to support operating system-level auditing.

There are, however, some disadvantages to impersonation. For example, it can reduce application scalability by using an inefficient pool database connection, and it can make administrators do more to create ACLs for an individual user.

Without impersonation:

  • Your application s users have a Windows account authenticated by a server.
  • You want to use fixed identity to access a downstream resource (for example, a database to support connection pooling).


Windows Authentication Configuration

Follow these steps before using the Windows authentication configuration mechanism:

  • Open IIS.
  • Right-click on the application folder and select the properties.
  • Select the Directory Security tab in the new opened window (see Figure 5).
  • At the Anonymous access and authentication control panel click the Edit button.
  • The Authentication Methods window appears; uncheck Anonymous access; Integrated Windows authentication should be selected by default (see Figure 6).


Figure 5: Windows authentication configuration.


Figure 6: Windows authentication configuration.

Likewise, you need to force application users to log on to your site in one of two ways: disable anonymous access in IIS and the web.config file or use NTFS permission to preclude anonymous accessing. You must write these lines into the web.config or machine.config file to configure a .NET application to impersonate an IIS authenticated caller:


Windows ACLs (Access Control Lists). You can configure Windows ACLs on resources accessed by your application (files, folders, registry keys, Active Directory objects, etc.) against the original caller. In other words, you can create file system permissions on specific application files. The ASP.NET FileAuthorizationModule class performs access checks for requested file types that are mapped to the ASP.NET ISAPI DLL. Thus, you can define which clients have access to which resources by creating and modifying the ACLs associated with those resources and by enabling and disabling client privileges.

URL authorization. URL authorization specifies which pages can be accessed based on users or roles (you can restrict users and roles by denying or allowing keywords); simply put the authorization tag into the web.config file:




For example:






Note: * refers to all identities (anonymous and authenticated) and ? refers to anonymous identity. Add or to the authorization tag, otherwise unauthenticated users are known as authenticated users. URL authorization only applies to file types that are mapped by IIS to the ASP.NET ISAPI extension aspnet_isapi.dll. You can use a location tag to determine authorization for a specific page. In Windows authentication mode, you must use a Windows and Users account to authorize. The User names take the form DomainName\WindowsUserName and Role names take the form DomainName\WindowsGroupName . For example, the local administrators group is referred to as BUILTIN\Administrators ; the local users group is referred to as BUILTIN\Users .

Enterprise Services (COM+) Roles. Roles are maintained in the COM+ catalog. You can configure roles with the Component Services administration tool or script. Note: The main difference between authentication with or without impersonation simply concerns Enterprise Services (COM+) Roles. Authentication with impersonation can use Enterprise Services (COM+) Roles, whereas authentication without impersonation is not allowed to use Enterprise Services (COM+) Roles.


Programmatic Security

Sometimes you want to apply and manage application security by your own custom mechanism at the application level. This is known as programmatic security. The following methods are applied to use programmatic security.

.NET Principal Objects. WindowsPrincipal Object. This object helps you control access to your code with a defined Windows user account. It is automatically created when you use Windows authentication in IIS. An instance of WindowsIdentity is needed to use this object:

//Get the current identity and put it into an identity object.

WindowsIdentity TestId = WindowsIdentity.GetCurrent();

//Put the previous identity into a principal object.

WindowsPrincipal Prin = new WindowsPrincipal(TestId); 

GenericPrincipal Object. Use this object with your own custom roles, which may be stored in a database; you can then populate them into the OnAuthenticate event. An instance of WindowsIdentity is needed to use this object:

//Create generic identity.

GenericIdentity TestId = new GenericIdentity("TestId");

//Create generic principal.

String[] StrArray = {"Manager", "Supervisor"}; 

GenericPrincipal Prin = new GenericPrincipal(TestId, StrArray); 

Explicit Role Checks. .NET security is the top level of Windows security. Windows security is based on security context provided by the logon session; the .NET Framework is based on IPrincipal and IIdentity objects. You can perform role checking using the IPrincipal or IIdentity interface:


Enterprise Services (COM+) Roles. You can perform role checking programmatically using the ContextUtil class:



Forms Authentication

Forms authentication is a custom mechanism that allows you to authenticate user credentials with information that you saved in your desired data store, such as a database or XML files (see Figure 7). The Forms authentication mechanism is based on browser cookies, so after you give an authentication ticket to each user, it helps you restrict access to your site s pages.

Figure 7: Forms authentication.

The three .NET classes most often used with Forms authentication are: FormsAuthentication, FormsAuthenticationTickets, and FormsIdentity. You can use this mechanism when you don t want to use a Windows accounts, or when you need to verify a user s access by its credential.

You can provide authorization based on user name or role membership. So, you can use programmatic security to perform fine-grained authorization within methods. For example, you can use explicit role checks such as IPrincipal.IsInRole. If you decide to use Forms authentication, you must follow these steps:

  • Configure IIS for anonymous access.
  • Configure ASP.NET for Forms authentication.
  • Create a logon Web form (include user name and password fields) and validate the supplied credentials.
  • Retrieve a list of roles from the custom data store.
  • Create a Forms authentication ticket (store roles in the ticket).
  • Create an IPrincipal object.
  • Put the IPrincipal object into the current HTTP context.
  • Authorize the user based on user name/role membership.

To configure IIS for anonymous access, start IIS using the administrative tools. Select your application s virtual directory, right-click, and select Properties. Click on Directory Security. Select Edit in the Anonymous access and authentication control group; select Anonymous access. Use this code to configure ASP.NET for Forms authentication:







   path="/" >         




If you want more security options, you can customize the machineKey tag, which is used to encrypt, decrypt, and validate the authentication ticket for Forms authentication. This tag is located within the machine.config file and has three elements; its default setting is:


To use machineKey you must set the protection element to Encryption. The validationKey attribute is used to create and validate Message Authentication Code (MAC) for the Forms authentication ticket and viewstate.

  • Forms authentication. In this case, the FormsAuthentication.Encrypt method is called, then the ticket value and validationKey compute a MAC that is appended to the cookie. When the FormsAuthentication.Decrypt method is called, a MAC is computed and compared with the appended MAC in the cookie.
  • Viewstate. The value of the viewstate and validationKey computes a MAC and appends it to the viewstate. When the client is posted back, MAC recomputes and compares it to the one appended to the viewstate.

The decryptionKey attribute is used to encrypt and decrypt the Forms authentication ticket and viewstate.

  • Forms authentication. When each of the FormsAuthentication.Encrypt or FormsAuthentication.Decrypt methods is called, the ticket value will encrypt or decrypt based on the decryptionKey value.
  • Viewstate. The value of viewstate is encrypted when it s sent to the client, and decrypted when it s posted back to the server.

Using the validation attribute you specify which algorithm shall be implemented for encryption, decryption, or validation. The available algorithms are:

  • SHA1. This is a keyed algorithm that can produce a 160-bit (20-byte) hash or digest of input value.
  • MD5. This produces a 20-byte hash using the MD5 algorithm.
  • 3DES. This stands for triple DES, but it s not applicable to Forms authentication.

Next, put the IPrincipal object into the current HTTP context. The main benefit of dividing users into specific roles is that you can define an access level for each group, then add it to HTTP context. Therefore, you must add these lines of code to the Application_AuthenticationRequest method in the Global.asax file for authenticated users:

String roles = ("Manager|Employee|Sales");

Context.User CUI = new GenericPrincipal(

 Context.User.Identity, roles); 

Note: Retrieve a role list from the custom data store and store a delimited list of roles within the UserData property of the FormsAuthenticationTicket class. This improves performance by eliminating repeated access to the data store for each Web request and saves you from storing the user s credentials in the authentication cookie. For each request after initial authentication:

  • Retrieve the roles from the ticket in the Application_AuthenticateRequest event handler.
  • Create an IPrincipal object and store it in the HTTP context (HttpContext.User). The .NET Framework also associates it with the current .NET thread (Thread.CurrentPrincipal).
  • Use the GenericPrincipal class (unless you have a specific need to create a custom IPrincipal implementation; for example, to support enhanced RoleBased operations).

It is recommended to use two cookies; one for personalization and one for secure authentication and authorization. Make the personalization cookie persistent (make sure it doesn t contain information that would permit a request to perform a restricted operation; for example, placing an order within a secure part of a site). Ensure cookies are enabled within the client browser. You must use aspnet_isapi.dll if you want to use other file types for Forms authentication.

Now create a logon Web form. In this case, create a simple Web form; for example, one that includes two labels and two textboxes (one for user name and one for password). You also must configure the web.config file to authentication and authorization goals:



And you can also deny access for all unauthenticated requests to your application page(s):




You also must create a credential validation method against a database by using ADO.NET objects. In this regard you should write a method to validate user information against registered information in your database. In addition to validating a user s information, you need a method to retrieve a user s role from a SQL Server database or Active Directory to apply an access level:

string roles = GetRoles(txtUserName.Text, txtPassword.Text);


Create a Forms Authentication Ticket

After creating a credential validation method and one to retrieve a user s role, you must handle it from an event. As you can see in Figure 8, after a user clicks the logon button, their credential is checked by the CredValidation method. Then your GetRoles method assigns and stores roles in the ticket.

// Validate credentials against either a SQL Server database or Active Directory

bool isAuthenticated = CredValidate(txtUserName.Text, txtPassword.Text );

If (isAuthenticated == true)


string roles = RetrieveRoles(txtUserName.Text, txtPassword.Text);

/* Create the authentication ticket and store the roles in the custom UserData

  property of the authentication ticket */

FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(

1,                          // Represent the version number of Ticket //

txtUserName.Text,           // user name of Ticket owner //

DateTime.Now,               // Creation time of Ticket //

DateTime.Now.AddMinutes(20),// Expiration time of Ticket //

false,                      // Determine user persistent //

roles );                    // The roles of user //

// Encrypt the ticket.

string encryptedTicket = FormsAuthentication.Encrypt(authTicket);

// Create a http cookie and add the encrypted ticket to it as data.

HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName,encryptedTicket);

// Add the cookie to the outgoing cookies collection.


// Redirect the user to the originally requested page.




Figure 8: Check credentials, then assign and store the roles in a ticket.


Microsoft Passport Authentication

Passport is one of the Web-based services that makes user authentication of your site faster and more reliable. It is a centralized authentication mechanism for the users who registered their information at the Microsoft Passport site. The user of each participating site should be authenticated before they can access restricted pages, so users should be redirected to the Passport site and, after successful login, automatically redirected back to the site.

It s not a free service; you must pay about $10,000 per year. But at this time, approximately 120,000,000 users are registered and have Passport ID, which makes its use more reasonable.

Authentication versus authorization. Microsoft Passport provides authentication service only. This means you must use your application-defined mechanism to gain authorization service for restricted access to your site resources.

There are two major advantages to Passport authentication:

  • Users prefer to use their existing login information instead of creating a new one for each site (with the possibility of forgetting them).
  • Site administrators don t need to implement any other mechanism to preserve their user registration information.

Passport Manager and PassportIdentity. The Passport Manager is a base component that connects participating Web sites to Passport authentication servers; PassportIdentity is a primary component that helps control the Passport Manager.

The Passport Manager can protect and encrypt a user s data from malicious work, and it handles all cookie settings without the need for manual changes. The Passport Manager Administrative Utility is a graphical interface of Passport Manager that helps to change the parameters of PassportIdentity. Passport Manager is included with Windows Server 2003 and you can run it by typing msppcnfg.exe at the run command box. However, for Windows XP you should download and install Passport Manager to configure it. To use PassportIdentity in ASP.NET pages, first make some changes in the web.config file to enable Passport authentication (see Figure 9).










Figure 9: Enabling Passport authentication.

PassportIdentity must be instantiated from its namespace:

System.Web.Security.PassportIdentity PID =



PassportIdentity must be instantiated on each page, because single instantiation may cause failure in read and write during the load and unload processes, and multiple instantiation has memory overhead, which can lead to adverse side effects on performance.


Verify User Authentication

You can use code to determine the authentication status of the user and also to customize the appearance of the page with a specific Passport logo (see Figure 10). It is recommended you clear the query string of the browser s address to avoid any malicious user attacks.

void Page_Load(Object sender, EventArgs e) {

 PassportIdentity PID = Context.User.Identity;

 // if the user Is Authenticated Clear query string //

 if (PID.GetFromNetworkServer) 


 //Change the passport logo image base on Authenticated

 //or None Authenticated User //

 if (PID.IsAuthenticated)

  Authlogo.Visible = true;


  NoneAuthlogo.Visible = true; 

Figure 10: Verifying authentication status.

After user registration, the user profile is saved on the Microsoft Passport servers and the participating site does not have direct access to its user profile but they can request a profile indirectly by using the GetProfileObject method of PassportIdentity. The user profile attributes are listed in Figure 11.















Flags Gender








Figure 11: User profile attributes.

Passport has two distinctive environments: preproduction and production. Preproduction works as a pilot environment to develop the stage of the participating Web site. It s a real-world simulation that helps developers test and validate their code. Production is the real-world environment that s accessible for the site s users. Participating Web sites may want to test their Passport components first in the preproduction environment; then, after resolving any problems, bring them up to the production environment.

Passport uses two kinds of cookies (instead of session-state variables): Domain-Authority and Participating Site. The cookies listed in Figure 12 are available from * (* refers to participating site name) and can only be used with the Microsoft Passport site.

Cookie Name





Encrypted with Microsoft Passport Key and contains profile attributes.



Used when your site uses SSL authentication.



Encrypted with Microsoft Passport Key and contains Passport timestamp, such as last sign-in, saved-password flag.



Sent using https protocol for all browsers that allow https cookies.

Visited Sites


Deletes all Sign ID of participating sites during sign-out process.

Figure 12: Domain-Authority cookies.

The cookies listed in Figure 13 are available to participating sites. When you configure Passport Manager, you can define the store location of the cookies to the root domain (Cookie Domain) or another path (Cookie Path). But by default, they are written to the root domain of the site, and participating sites are responsible to delete all the cookies when they want to sign out.

Cookie Name





Encrypted with Microsoft Passport Key and contains user s consent status.



Encrypted with Microsoft Passport Key and contains profile attributes.



Used when your site uses SSL authentication.



Encrypted with Microsoft Passport Key and contains passport timestamp, such as last sign-in, saved-password flag.

Figure 13: Participating Site cookies.


To refer each user of participating sites, Passport must use a unique ID. The specific attribute most appropriate for this is sign-in name. Although it is unique, based on security reasons it is not stored in the Passport profiles. Member Name cannot be unique because it is possible that many registered users have the same name. Preferred Email is not a required attribute, so it cannot be used as a unique identifier. Therefore, the unique identifier that Passport needs must have two major futures: uniqueness and security.

Passport uses Passport Unique Identifier (PUID), which represents the attributes MemberIDLow and MemberIDHigh. Each attribute has eight characters in a string. To use this unique identifier in your Web site pages you must write this code at the beginning of each page:

System.Web.Security.PassportIdentity PID =



To authenticate users, the sign-in method is applied:

  • Instantiate the PassportIdentity object.
  • Detect authentication data with the GetFromNetworkServer property of PassportIdentity.
  • Verify authentication status with the GetIsAuthenticated method of PassportIdentity.
  • Check your database (see Figure 14); did the user grant consent for your site to keep their profile?
//User should be authenticated for an hour

if (PID.GetIsAuthenticated(3600,false,false))


  //Determine user's PID.

  string Memberidhigh, Memberidlow;

  Memberidhigh = PID.GetProfileObject("MemberIDHigh").ToString();

  Memberidlow = PID.GetProfileObject("MemberIDLow").ToString();

  // Check for this user's record in your consent database


   The LogoTag2 method used to returns an HTML fragment containing

   an image tag for a Microsoft Passport link.

   The image displays either the Sign In or Sign Out IMG source,

   as appropriate.


 if (ConsentIsInDatabase(Memberidhigh,Memberidlow))

   SignedIn = true;


   SignedIn = false;


Figure 14: Verify the user has granted consent for your site to keep their profile.

As mentioned, Passport uses cookie variables to save user-state variables. So any participating site has a series of cookies to keep the authentication state of users. Thereby, after each sign-out, all the cookies must be deleted. When the SignOut method calls, the first step is to determine which participating site the user is currently logged in to, then all the cookies from * must be deleted by SignOut. You specify the URL of the mentioned method using the Expire Cookie Url field in the .NET Service Manager when you configure it.

To implement sign-out, the user should be able to sign-out by each page that used the LogoTag2 method. Your site should also have a Site ID to delete the cookies. Then, verify that the Passport Manager installation has set cookies to the correct path. Finally, delete all the cookies used by assigning a null value, such as MSPAuth, MSPProf, etc.:

Response.ContentType = "image/gif";

   //Set content type to load GIF or JPEG into

   //Internet Explorer//

Response.Expires = -1;

Response.AddHeader("P3P", "CP="");

 //Allows cookies to be deleted by your site//

Response.Cookies("MSPProf").Value = "";

Response.Cookies("MSPProf").Expires = DateTime.MinValue;

   //Delete profile cookie//





This article has covered the authentication and authorization models that can be used in ASP.NET. Available authentication models are Windows, Forms, Passport, and none; available authorization models are Files, URL, Principal Objects, and .NET Roles. Keep in mind that the best security strategy can be implemented when you have detailed information about the authentication and authorization models of the technologies used in your application. For more information about ASP.NET security models visit

The sample code accompanying this article is available for download.


Ata Allah Yazdani is a software engineer and manager of the Analyzing and Defining Solution Architecture committee at Ashian, an IT consultancy and software development company. He can be reached at mailto:[email protected].

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.