Introduction

By default in an ASP.NET Web site, visitors can browse the site anonymously, load pages, and download the content we provide. They do not have to provide any credentials for example, by logging in to the site. For most Web sites, of course, this is just what we want. However, there are occasions, depending on the type of content we provide, when we want to force users to identify themselves before they access the content. This might be as soon as they arrive at the site, or it might be at some point such as a checkout, when they are buying goods, or just so that we can allocate forum posts this visitor makes to them like c-sharpcorner.com web portal.

Configuration Files

Most of the default configuration settings for ASP.NET web sites we create are in the web.config and machine.config files stored in the folder C\Windows\Microsoft.NET\Framework\v[version]\CONFIG\ of your PC. We can override most of these settings simply by placing a web.config file in the folders of your site or application. Visual Studio 2005 and Visual Web Developer can automatically create these files to enable debugging of pages as we build your site.
The <system.web> section of the web.config file can contain a section named <authorization> that controls access to the site and to individual subfolders with the site's virtual root. If there is no <authorization> in the local or default web.config file, the equivalent section in the configuration file for the machine, machine.config, provides the settings.

 <system.web>
...
<authorization>
<allow users="*" />
</authorization>
....
</system.web>

ASP.NET Authentication and Authorization

Once ASP.NET starts to process the request received from IIS, it does so using its own configuration and security settings. These are wholly contained in the machine.config file and more specifically the various web.config files in the root and subfolders of your Web site and application directories.
These are the settings the ASP.NET Web Administration Tool is specifically designed to manage.

ASP.NET Authentication Settings

The <authentication> element can appear in a web.config file in the root of your Web site or a virtual application root folder. It specifies the type of authentication ASP.NET uses, the specific settings for this authentication process and, optionally, the accounts that have access to ASP.NET resources.

<system.web>
...
<authentication mode="Windows|Forms|Passport|None">
<forms name="name"
path="/"
domain="domain name"
loginUrl="url"
defaultUrl="url"
protection="All|None|Encryption|Validation"
timeout="30"
slidingExpiration="true|false"
requireSSL="true|false"
cookieless="UseCookie|UseUri|UseDeviceProfile|AutoDetect"
enableCrossAppRedirects="[true|false]">
<credentials passwordFormat="Clear|SHA1|MD5">
<user name="username" password="password"/>
</credentials>
</forms>
<passport redirectUrl="internal"/>
</authentication>
...
</system.web>

The mode attribute specifies the type of authentication process. The three types are:

Using Forms Authentication

The most common authentication approach for public Web sites and Web applications is Forms authentication. This does not rely on any specific network protocols and works through firewalls and proxy servers as well as over the Internet. It is, in fact, similar to the custom techniques that Web site developers have used for many years. However, ASP.NET makes it easy to program and, in most cases, a lot more secure than customer techniques.

The <forms> element contains the following series of attributes that define the behavior of the authentication process:The <credentials> Element

Both Windows and Passport authentication techniques maintain a list of valid users, outside of your ASP.NET application. Windows stores its accounts details in an internal secure database on the server or the domain controller. The Microsoft Passport site stores user details centrally, and it does not expose them to your ASP.NET applications.
However, when we use Forms authentication, we must provide the list of valid users so that ASP.NET can validate logon requests. One way is to include the list of users in your web.config file in the <credentials> element. For each user, we include a <user> element that specifies the user name and password. To avoid storing plain text passwords, we can encrypt them using the delightfully named HashPasswordForStoringInConfigFile method of the System.Web.Security.FormsAuthentication class. We then specify the encryption type we used in the passwordFormat attribute of the <credentials> element.

Cookie-less Sessions and Cookie-less Forms Authentication

One issue that we might come across when using Forms authentication is that it depends on the client's browser accepting and then returning the special cookie that indicates they were authenticated. For clients that do not support cookies, or who have disabled them in their browser options, Forms authentication (together with session support and other features of ASP.NET) will fail to work correctly, because ASP.NET cannot then recognize users when they make a subsequent request.
To get around this, we can use cookie-less sessions and cookie-less Forms authentication methods. When we enable cookie-less sessions, ASP.NET inserts the session ID into the URL so that it recognizes the user on the next request. The <sessionState> element in the <system.web> section of web.config can specify that ASP.NET should use cookie-less sessions:

<sessionState cookieless="true" />

We specify cookie-less Forms authentication using the cookieless attribute of the <forms> element, as shown at the beginning of this current section. The FormsAuthentication class exposes the static CookiesSupported and CookieMode properties that provide information about the current configuration or the current user's cookie support.

ASP.NET Authorization Settings

Having specified the type of authentication we will use, we now have a technique that allows ASP.NET to identify visitors to the site, or to a specific subsection of the site. However, we also have to provide ASP.NET with information on what permissions and privileges each user should have. In other words, having identified a user, should ASP.NET allow that user to access a specific folder or resource?

<system.web>
...
<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>
...
</system.web>

There are two specific characters we can use in the users attribute of the <allow> and <deny> elements:

• The asterisk (*) means "all users"
• The question mark (?) means "anonymous users," in other words, users that have been authenticated by IIS within the context of the "IUSR_[machine-name]" account

The verbs attribute refers to specific types of HTTP request; the types recognized by ASP.NET are GET, HEAD, POST, and DEBUG. This means that we can allow or deny access based on the type of request. For example, we can allow specific users (or all users) to access pages only by using values in the query string (GET) and not when posting values from a <form>.

The most stringent rules take precedence, so that (when using Windows authentication) we can deny access to a Windows account group in the <deny> element but then allow access to a specific account within that group using the <allow> element.
We use the <authorization> element in a web.config file placed in the secured target folder of your site in other words, in the folder(s) where we want to limit access to specific authenticated users. These folders must be within the virtual application to which the <authentication> element applies. Alternatively, we can use the <location> element to target parts of a web.config file at a specific folder or resource, as shown in example

<configuration>
...
<system.web>
...
<authentication mode="Forms">
<forms name="myapp" path="/" loginUrl="login.aspx"
protection="All" requireSSL="true"
timeout="30" slidingExpiration=" false">
<credentials passwordFormat="Clear|SHA1|MD5">
<user name="alex" password="56&FEw%x2K"/>
</credentials>
</forms>
</authentication>
...
</system.web>
<location path="SecureArea"
<system.web>
<authorization>
<allow users="?"/>
</authorization>
</system.web>
</location>
...
</configuration>

HAVE A HAPPY CODING!