Authentication and Authorization | Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)

In ASP.NET, authentication is the process of establishing identity between the server and a request, to clearly establish that all the server really has is the data sent to it over HTTP. In other words, the server knows nothing about the client other than what the client sends the server. This is important since the application making a request is not always a browser. In fact, it would be wise to get out of the mentality that only web browsers will be making requests against your server.

To establish the identity of a request, the request must follow a protocol that enables a predefined set of rules to be adhered to. For example, almost all HTTP servers support clear text/basic authentication, the pop-up dialog box that asks for a username and password. Clear text/basic authentication follows a protocol such that the browser can properly formulate and encode the request in the format that the server expects.

ASP.NET provides four distinct options for assigning identity to a request:

Forms authentication :Allows you to authenticate requests using HTTP cookies and HTML forms. You can validate identity against any resource.
Passport authentication :Uses Microsoft's single sign-on Passport identity system.
Windows authentication :Allows you to authenticate requests using Windows Challenge/Response semantics. This consists of the server initially denying access to a request (a challenge) and the requestor responding with a hashed value of their Windows username/password, which the server can then choose to authenticate and/or authorize.
Custom authentication :Allows you to roll your own authentication system.

Authentication

ASP.NET's authentication system is very flexible. It supports four modes and various settings for each of these modes. The default mode is Windows , but you can configure support for the other modes using the mode attribute of the <authentication> element:

This attribute has four acceptable settings; Windows , Forms , Passport , and None . This value determines the authentication mode that ASP.NET will enforce. The default is Windows . If the mode is set to Forms , a child element of <authentication> (called <forms> ) allows you to define behaviors for forms authentication.

Custom HTML Forms Login

Forms authentication allows you to use HTML forms to request credentials, and then issue an HTTP cookie that the requestor may use for identity on subsequent requests. ASP.NET provides the infrastructure to support this, but also gives the flexibility to choose how you wish to validate credentials.

For example, once you obtain the username and password that has been sent to the ASP.NET application via HTTP POST (rather than HTTP GET as it passes the data on the query string), you can validate the credentials against an XML file, a database, an in memory structure, an LDAP directory, or even through a web service!

The validation of credentials is completely up to you. Once the credentials are validated , you can call some of the APIs provided by forms authentication to issue an HTTP cookie to the requestor. On subsequent requests, the cookie is provided along with the request body, and ASP.NET can use the information in the cookie to recreate a valid identity.

The <forms> element has the following attributes:

name :Forms authentication uses a cookie that contains an ID of the authenticated user . The name of that cookie is defined by the name value of <forms> . The default setting is .ASPXAUTH .
loginUrl :When a request comes into ASP.NET with forms authentication enabled, and the request doesn't present a cookie (new user) or has an invalid value within the cookie, ASP.NET will redirect the request to an ASP.NET page capable of logging in the user and issuing the cookie. loginUrl allows you to configure this value. By default, it is set to login.aspx and you must provide your implementation of this file.
protection :The value within the cookie can optionally be encrypted or sent in plain text. For sites that simply use forms authentication as a means of identifying the user, you might choose to use no cookie encryption. Valid settings for protection are All , None , Encryption , and Validation .
timeout :Specifies the time in minutes that the cookie is valid for. The timeout of the cookie is reset on each request to the current time plus the timeout value. The default value is 30 minutes.
path :Specifies the path value of the cookie. By default this is set to / , the root of the server. Cookies are only visible to the path and server that sets the cookie. ASP.NET forms authentication chooses to use the root of the server as the path, since the path value in a cookie is case-sensitive.
requireSSL ( ASP.NET 1.1 ):Defaults to false , but when set to true requires that the Forms Authentication cookie is sent using SSL. Using SSL for sending the cookie provides a better measure of security.

Within <forms> there is also a <credentials> sub-element , which can optionally be used to define users.

Note	As you will learn in Chapter 14, when we use forms authentication, you can validate users from any data store.

Defining Users for HTML Forms Authentication

Nested within the <forms> element is a <credentials> element. <credentials> allows you to define users (identities) and passwords directly within your configuration file, although this is completely optional. You can choose to take advantage of this section, or can choose to define identities in another location.

Important

Use of the <credentials> section is not required. Instead, the validation of the username and password can be custom-coded, such as validation of username/password pairs stored in a database.

The <credentials> section allows you to define <user> entries. This section is used to optionally store your usernames and passwords in the configuration file. <credentials> supports a single attribute, passwordFormat . This attribute tells ASP.NET the password format used by the password value of <user> . Supported values include SHA1 , MD5 , and Clear . However, simply setting this value does not automatically encrypt the value of password . It is the developer/administrator's responsibility to add the value of the SHA1 or MD5 hashed password into the configuration file.

Nested within <credentials> are <user> entries. The <user> entries are used to define valid usernames and passwords against which to authenticate. A <user> entry contains two attributes “ name and password “ that together are compared against when we attempt to authenticate requests.

If you choose to store your usernames and passwords in the configuration file, you are provided with several options for password hiding. The <credentials> tag supports a single passwordFormat attribute. This attribute can be set to one of three values:

Clear :Value of the password for <user> entries is stored in clear text. For example, password="password" .
SHA1 :Value of the password for <user> entries is stored as a SHA1 hash. For example, password="5B9FEBC2D7429C8F2002721484A71A84C12730C7" (value is password). Hashing will be discussed in the next chapter.
MD5 :Value of the password for <user> entries is stored as an MD5 hash. For example, password="2BF3023F1259B0C2F607E4302556BD72" (value is password).

Rather than storing clear text values within the <credentials> section for <user> entries, you can store hashes of the password. If your configuration file is compromised, the users' passwords are safer than if they were stored as clear text.

An example of storing the username and password in the credentials section is shown next. The passwordFormat is set to SHA1 and the value for password represents a SHA1 hash of the user's password:

 <configuration>    <system.web>  <authentication mode="Forms">   <forms name=".ASPXAUTH" loginUrl="login.aspx"   protection="all" timeout="30" path="/" >   <credentials passwordFormat="SHA1">   <user name="SomeUser" password="83jksjfi3983ksl23dscdf"/>   </credentials>   </forms>   </authentication>  </system.web> </configuration>

Passport Authentication

When Passport is installed on the server, ASP.NET's Passport integration can be utilized to authenticate users, based on whether they present a valid Passport with their request. The Passport is a token granted to a given request that enables the request to be authenticated by applications that trust Passport IDs.

The token is stored in a site-specific cookie after authenticating with login.passport.com . You can use the redirectUrl attribute of the <passport> authentication option to control where non-authenticated Passport users are directed. For example:

  <passport redirectUrl="/Passport/SignIn.aspx">

Depending upon how you configure your site's authorization (discussed next), this may be the only page that Passport users are allowed to access.

Note	We will explore authentication in more detail in Chapter 14.

Authorization

The <authorization> configuration settings allow you to set access control permissions, defined as <allow> and <deny> settings, used to control access to resources. Both follow the same format for entries:

 <[allow  deny] users="users  *  ?" roles="roles"/>

For example:

 <configuration>    <system.web>  <authentication mode="Forms">   <forms name=".ASPXAUTH" loginUrl="login.aspx"   protection="all" timeout="30" path="/" >   </forms>   </authentication>   <authorization>   <allow users="Stephen, Brian, Rob" roles="Administrator, Customer" />   <deny users="?" roles="BlackList" />   </authorization>   </system.web>  </configuration>

Note	Note the ordering of the <allow> and <deny> . This controls how the authorization is enforced, <deny> should follow the <allow> .

In the configuration settings, we define authorization settings that allow the users Stephen , Brian , and Rob as well as the Administrator and Customer roles. However, anonymous users (identified by ? ) and users that belong to the BlackList role/ group will be denied access. Any users or roles that are denied access will be redirected to the loginUrl specified in the authentication settings, since the server will attempt to re-authenticate the user.