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?
<authorization>
<allow .../>
<deny .../>
</authorization>
allow : Adds to the mapping of authorization rules an authorization rule that allows access to a resource.
deny : Adds to the mapping of authorization rules an authorization rule that denies access to a resource.
Configurable locations
<authorization>
<allow .../>
<deny .../>
</authorization>
allow : Adds to the mapping of authorization rules an authorization rule that allows access to a resource.
deny : Adds to the mapping of authorization rules an authorization rule that denies access to a resource.
Configurable locations
- Machine.config
- Root-level Web.config
- Application-level Web.config
- Virtual or physical directory–level Web.config
Configures the ASP.NET authentication scheme that is used to identify users who view an ASP.NET application.
<authentication mode="[Windows|Forms|Passport|None]" >
<forms>...</forms>
<passport/>
</authentication>
Windows:
Specifies Windows authentication as the default authentication mode. Use it with any form of Microsoft Internet Information Services (IIS) authentication: Basic, Digest, Integrated Windows authentication (NTLM/Kerberos), or certificates. In this case, your application delegates the authentication responsibility to the underlying IIS.
Forms:
Specifies ASP.NET forms–based authentication as the default authentication mode.
Passport:
Specifies Microsoft Passport Network authentication as the default authentication mode.
None:
Specifies no authentication. Your application expects only anonymous users or the application provides its own authentication.
The authentication element configures the ASP.NET authentication scheme for an ASP.NET application. The authentication scheme determines how to identify users who want to view the ASP.NET application.
Configurable locations
<authentication mode="[Windows|Forms|Passport|None]" >
<forms>...</forms>
<passport/>
</authentication>
Windows:
Specifies Windows authentication as the default authentication mode. Use it with any form of Microsoft Internet Information Services (IIS) authentication: Basic, Digest, Integrated Windows authentication (NTLM/Kerberos), or certificates. In this case, your application delegates the authentication responsibility to the underlying IIS.
Forms:
Specifies ASP.NET forms–based authentication as the default authentication mode.
Passport:
Specifies Microsoft Passport Network authentication as the default authentication mode.
None:
Specifies no authentication. Your application expects only anonymous users or the application provides its own authentication.
The authentication element configures the ASP.NET authentication scheme for an ASP.NET application. The authentication scheme determines how to identify users who want to view the ASP.NET application.
Configurable locations
- Machine.config
- Root-level Web.config
- Application-level Web.config
ASP.Net Applications of XML have been integrated into such an extent that XML format for the exchange of data, it's also used to store configuration settings.
The Web.config is an XML file, it can consist of any valid XML tags, but the root element should always be <configuration>. Nested within this tag you can include various other tags to describe your settings. Since a Web.config file comes as a standard when you start to build a new Web application.
The default XML file generated by Visual Studio .NET:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>
<customErrors
mode="RemoteOnly"
/>
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<trace
enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"
/>
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>
</system.web>
</configuration>
The <configuration> tag has only one child tag, which we call section group, the <system.web> tag. A section group typically contains the setting sections, such as: compilation, customErrors, authentication, authorization, etc. The way this works is pretty straightforward: you simply include your settings in the appropriate setting sections. You want to use a different authentication mode for your Web application, you'd change that setting in the authentication section.
Apart from the standard system.web settings, you can define your own specific application settings, such as a database connection string, using the <appSettings> tag. Consequently, your most common Web.config outline would be:
<configuration>
<system.web>
<!— sections-->
</system.web>
<appSettings>
<!— sections -->
</appSettings >
</configuration>
Let's discuss the details of both section groups now.
The system.web Section Group
In this section group, you'll include configuration settings that, you'd have set up somewhere in the IIS administration console. At Microsoft's MSDN Library, you can find an overview of all the tags that the system.web section group understands, but, depending on the complexity of your site, you may not ever use even half of those options.
<authentication>
The authentication section controls the type of authentication used within your Web application, as contained in the attribute mode. You'll enter the value "None" if anyone may access your application. If authentication is required, you'll use "Windows", "Forms" or "Passport" to define the type of authentication. For example:
<authentication mode="Windows" />
<authorization>
To allow or deny access to your web application to certain users or roles, use <allow> or <deny> child tags.
<authorization>
<allow roles="Administrators,Users" />
<deny users="*" />
</authorization>
It's important to understand that ASP.NET's authorization module iterates through the sections, applying the first rule that corresponds to the current user. In this example, users carrying the role Administrators or Users will be allowed access, while all others (indicated by the * wildcard) will encounter the second rule and will subsequently be denied access.
<compilation>
Here, you can configure the compiler settings for ASP.NET. You can use loads of attributes here, of which the most common are debug and defaultLanguage. Set debug to "true" only if you want the browser to display debugging information. Since turning on this option reduces performance, you'd normally want to set it to "false". The defaultLanguage attribute tells ASP.NET which language compiler to use, since you could use either Visual Basic .NET or C# for instance. It has value vb by default.
<customErrors>
To provide your end users with custom, user-friendly error messages, you can set the mode attribute of this section to On. If you set it to RemoteOnly, custom errors will be shown only to remote clients, while local host users will see the ugly but useful ASP.NET errors -- clearly, this is helpful when debugging. Setting the mode attribute to Off will show ASP.NET errors to all users.
If you supply a relative (for instance, /error404.html) or absolute address (http://yourdomain.com/error404.html) in the defaultRedirect attribute, the application will be automatically redirected to this address in case of an error. Note that the relative address is relative to the location of the Web.config file, not the page in which the error takes place. In addition you can use <error> tags to provide a statusCode and a redirect attribute:
<customErrors mode="RemoteOnly" defaultRedirect="/error.html">
<error statusCode="403" redirect="/accessdenied.html" />
<error statusCode="404" redirect="/pagenotfound.html" />
</customErrors>
<globalization>
The globalization section is useful when you want to change the encoding or the culture of your application. Globalization is such an extensive subject that an entire article could be dedicated to the matter. In short, this section allows you to define which character set the server should use to send data to the client (for instance UTF-8, which is the default), and which settings the server should use to interpret and displaying culturally specific strings, such as numbers and dates.
<globalization requestEncoding="utf-8" responseEncoding="utf-8"
culture="nl-NL" />
Encoding is done through the attributes requestEncoding and responseEncoding. The values should be equal in all one-server environments. In this example, the application culture is set to Dutch. If you don't supply a culture, the application will use the server's regional settings.
<httpRuntime>
You can use the httpRuntime section to configure a number of general runtime settings, two of which are particularly convenient.
<httpRuntime appRequestQueueLimit="100" executionTimeout="600" />
The first attribute specifies the number of requests the server may queue in memory at heavy-traffic times. In the example, if there are already 100 requests waiting to be processed, the next request will result in a 503 error ("Server too busy").
The executionTimeout attribute indicates the number of seconds for which ASP.NET may process a request before it's timed out.
<sessionState>
In this section of the Web.config file, we tell ASP.NET where to store the session state. The default is in the process self:
<sessionState mode="InProc" />
Session variables are very powerful, but they have a few downsides. Information is lost when the ASP.NET process crashes, and sessions are generally useless in the case of a Web farm (multiple Web servers). In that instance, a shared session server can solve your issues. It's beyond the scope of this article to expand on this topic, but it's worth a mention. More information on sessionState can be found in the MSDN Library online.
<trace>
Your application's trace log is located in the application root folder, under the name trace.axd. You can change the display of tracing information in the trace section.
The attributes you will look for initially are enabled: localOnly, and pageOutput.
<trace enabled="true" localOnly="true" pageOutput="false" />
Set localOnly to "false" to access the trace log from any client. If you set the value of pageOutput to "true", tracing information will be added to the bottom of each Web page.
The appSettings Section Group
Apart from the Website configuration settings I've been talking about in the preceding paragraphs, you'll know that a programmer frequently likes to use custom application-wide constants to store information over multiple pages. The most appealing example of such a custom constant is a database connection string, but you can probably think of dozens more from your own experience.
The common denominator of these constants is that you want to retrieve their values programmatically from your code. The Web.config file provides the possibility to do so, but as a security measure, these constants have to be included in the <appSettings> section group. Just like <system.web>, <appSettings> is a direct child tag of the Web.config's configuration root.
A typical custom section group would look something like this:
<appSettings>
<add key="sqlConn" value="Server=myPc;Database=Northwind" />
<add key="smtpServer" value="smtp.mydomain.com" />
</appSettings>
This example shows that keys and values can be included in the custom application settings via an <add> tag. The way to access such a value in any of your Web pages is illustrated below:
ConfigurationSettings.AppSettings("sqlConnection")
- A Web application can contain more than one Web.config file. The settings in a file apply to the directory in which it's located, and all child directories. Web.config files in child directories take precedence over the settings that are specified in parent directories.
- Web.config files are protected by IIS, so clients cannot get to them. If you try to retrieve an existing http://?????.com/Web.config file, you'll be presented with an "Access denied" error message.
- IIS monitors the Web.config files for changes and caches the contents for performance reasons. There's no need to restart the Web server after you modify a Web.config file.
The Web.config is an XML file, it can consist of any valid XML tags, but the root element should always be <configuration>. Nested within this tag you can include various other tags to describe your settings. Since a Web.config file comes as a standard when you start to build a new Web application.
The default XML file generated by Visual Studio .NET:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>
<customErrors
mode="RemoteOnly"
/>
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<trace
enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"
/>
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>
</system.web>
</configuration>
The <configuration> tag has only one child tag, which we call section group, the <system.web> tag. A section group typically contains the setting sections, such as: compilation, customErrors, authentication, authorization, etc. The way this works is pretty straightforward: you simply include your settings in the appropriate setting sections. You want to use a different authentication mode for your Web application, you'd change that setting in the authentication section.
Apart from the standard system.web settings, you can define your own specific application settings, such as a database connection string, using the <appSettings> tag. Consequently, your most common Web.config outline would be:
<configuration>
<system.web>
<!— sections-->
</system.web>
<appSettings>
<!— sections -->
</appSettings >
</configuration>
Let's discuss the details of both section groups now.
The system.web Section Group
In this section group, you'll include configuration settings that, you'd have set up somewhere in the IIS administration console. At Microsoft's MSDN Library, you can find an overview of all the tags that the system.web section group understands, but, depending on the complexity of your site, you may not ever use even half of those options.
<authentication>
The authentication section controls the type of authentication used within your Web application, as contained in the attribute mode. You'll enter the value "None" if anyone may access your application. If authentication is required, you'll use "Windows", "Forms" or "Passport" to define the type of authentication. For example:
<authentication mode="Windows" />
<authorization>
To allow or deny access to your web application to certain users or roles, use <allow> or <deny> child tags.
<authorization>
<allow roles="Administrators,Users" />
<deny users="*" />
</authorization>
It's important to understand that ASP.NET's authorization module iterates through the sections, applying the first rule that corresponds to the current user. In this example, users carrying the role Administrators or Users will be allowed access, while all others (indicated by the * wildcard) will encounter the second rule and will subsequently be denied access.
<compilation>
Here, you can configure the compiler settings for ASP.NET. You can use loads of attributes here, of which the most common are debug and defaultLanguage. Set debug to "true" only if you want the browser to display debugging information. Since turning on this option reduces performance, you'd normally want to set it to "false". The defaultLanguage attribute tells ASP.NET which language compiler to use, since you could use either Visual Basic .NET or C# for instance. It has value vb by default.
<customErrors>
To provide your end users with custom, user-friendly error messages, you can set the mode attribute of this section to On. If you set it to RemoteOnly, custom errors will be shown only to remote clients, while local host users will see the ugly but useful ASP.NET errors -- clearly, this is helpful when debugging. Setting the mode attribute to Off will show ASP.NET errors to all users.
If you supply a relative (for instance, /error404.html) or absolute address (http://yourdomain.com/error404.html) in the defaultRedirect attribute, the application will be automatically redirected to this address in case of an error. Note that the relative address is relative to the location of the Web.config file, not the page in which the error takes place. In addition you can use <error> tags to provide a statusCode and a redirect attribute:
<customErrors mode="RemoteOnly" defaultRedirect="/error.html">
<error statusCode="403" redirect="/accessdenied.html" />
<error statusCode="404" redirect="/pagenotfound.html" />
</customErrors>
<globalization>
The globalization section is useful when you want to change the encoding or the culture of your application. Globalization is such an extensive subject that an entire article could be dedicated to the matter. In short, this section allows you to define which character set the server should use to send data to the client (for instance UTF-8, which is the default), and which settings the server should use to interpret and displaying culturally specific strings, such as numbers and dates.
<globalization requestEncoding="utf-8" responseEncoding="utf-8"
culture="nl-NL" />
Encoding is done through the attributes requestEncoding and responseEncoding. The values should be equal in all one-server environments. In this example, the application culture is set to Dutch. If you don't supply a culture, the application will use the server's regional settings.
<httpRuntime>
You can use the httpRuntime section to configure a number of general runtime settings, two of which are particularly convenient.
<httpRuntime appRequestQueueLimit="100" executionTimeout="600" />
The first attribute specifies the number of requests the server may queue in memory at heavy-traffic times. In the example, if there are already 100 requests waiting to be processed, the next request will result in a 503 error ("Server too busy").
The executionTimeout attribute indicates the number of seconds for which ASP.NET may process a request before it's timed out.
<sessionState>
In this section of the Web.config file, we tell ASP.NET where to store the session state. The default is in the process self:
<sessionState mode="InProc" />
Session variables are very powerful, but they have a few downsides. Information is lost when the ASP.NET process crashes, and sessions are generally useless in the case of a Web farm (multiple Web servers). In that instance, a shared session server can solve your issues. It's beyond the scope of this article to expand on this topic, but it's worth a mention. More information on sessionState can be found in the MSDN Library online.
<trace>
Your application's trace log is located in the application root folder, under the name trace.axd. You can change the display of tracing information in the trace section.
The attributes you will look for initially are enabled: localOnly, and pageOutput.
<trace enabled="true" localOnly="true" pageOutput="false" />
Set localOnly to "false" to access the trace log from any client. If you set the value of pageOutput to "true", tracing information will be added to the bottom of each Web page.
The appSettings Section Group
Apart from the Website configuration settings I've been talking about in the preceding paragraphs, you'll know that a programmer frequently likes to use custom application-wide constants to store information over multiple pages. The most appealing example of such a custom constant is a database connection string, but you can probably think of dozens more from your own experience.
The common denominator of these constants is that you want to retrieve their values programmatically from your code. The Web.config file provides the possibility to do so, but as a security measure, these constants have to be included in the <appSettings> section group. Just like <system.web>, <appSettings> is a direct child tag of the Web.config's configuration root.
A typical custom section group would look something like this:
<appSettings>
<add key="sqlConn" value="Server=myPc;Database=Northwind" />
<add key="smtpServer" value="smtp.mydomain.com" />
</appSettings>
This example shows that keys and values can be included in the custom application settings via an <add> tag. The way to access such a value in any of your Web pages is illustrated below:
ConfigurationSettings.AppSettings("sqlConnection")
| Related Topic: |
When the site goes live change the debug setting to false which will make the site have a little better performance.
<compilation defaultLanguage="C#" debug="true" />
Customer errors can be handled be turned off but I prefer them to be turned on as below.
<customErrors mode="Off" />
You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.
<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true"/>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
</configuration>
Multiple File Configuration
The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="dbsettings.config"/>
</configuration>
Next, we can create the external file ‘dbsettings.config’ and add an appSettings section with our connection information.
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
Session States:
Session in Asp .net web application is very important. As we know that HTTP is a stateless protocol and we needs session to keep the state alive. Asp .net stores the sessions in different ways. By default the session is stored in the asp .net process. You can always configure the application so that the session will be stored in one of the following ways
[1] Session State Service
There are two main advantages of using the State Service. First the state service is not running in the same process as the asp .net application. So even if the asp .net application crashes the sessions will not be destroyed. Any advantage is sharing the state information across a Web garden (Multiple processors for the same computer).
Lets see a example of the Session State Service.
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:55455" sqlConnectionString="data source=127.0.0.1;user id=sa;password='' cookieless="false" timeout="20"/>
The attributes are self explanatory but I will go over them.
mode: This can be StateServer or SqlServer. Since we are using StateServer we set the mode to StateServer.
stateConnectionString: connectionString that is used to locate the State Service.
sqlConnectionString: The connection String of the sql server database.
cookieless: Cookieless equal to false means that we will be using cookies to store the session on the client side.
[2.] SQL Server
The final choice to save the session information is using the Sql Server 2000 database. To use Sql Server for storing session state you need to do the following:
Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store the session.
You web.config settings will look something like this:
<sessionState mode = "SqlServer" stateConnectionString="tcpip=127.0.0.1:45565" sqlConnectionString="data source="SERVERNAME;user id=sa;password='' cookiesless="false" timeout="20"/>
SQL Server lets you share session state among the processors in a Web garden or the servers in a Web farm. Apart from that you also get additional space to store the session. And after that you can take various actions on the session stored.
The downside is SQL Server is slow as compared to storing session in the state in process. And also SQL Server cost too much for a small company.
[3] InProc:
This is another Session State. This one is mostly used for development purposes. The biggest advantage of using this approach is the applications will run faster when compared to other Session state types. But the disadvantage is Sessions are not stored when there is any problem that occurs with the application, when there is a small change in the files etc., Also there could be frequent loss of session data experienced.
Error Handling:
<customErrors mode = "On">
<error statusCode = "404" redirect = "errorPage.aspx" />
</customErrors>
Security:
The most critical aspect of any application is the security. Asp.net offers many different types of security method which can be used depending upon the condition and type of security you need.
[1] No Authentication:
No Authentication means "No Authentication" :) , meaning that Asp.net will not implement any type of security.
[2] Windows Authentication:
The Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. If you like to see that what windows user is using the Asp.net application you can use:
User.Identity.Name;
This returns the DOMAIN\UserName of the current user of the local machine.
[3] Passport Authentication:
Passport Authentication provider uses Microsoft's Passport service to authenticate users.
[4] Forms Authentication:
Forms Authentication uses HTML forms to collect the user information and than it takes required actions on those HTML collected values.
In order to use Forms Authentication you must set the Anonymous Access checkbox checked. Now we need that whenever user tries to run the application he/she will be redirected to the login page.
<authentication mode="Forms">
<forms loginUrl = "frmLogin.aspx" name="FAutho" timeout="1"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>
<compilation defaultLanguage="C#" debug="true" />
Customer errors can be handled be turned off but I prefer them to be turned on as below.
<customErrors mode="Off" />
You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.
<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true"/>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
</configuration>
Multiple File Configuration
The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="dbsettings.config"/>
</configuration>
Next, we can create the external file ‘dbsettings.config’ and add an appSettings section with our connection information.
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
Session States:
Session in Asp .net web application is very important. As we know that HTTP is a stateless protocol and we needs session to keep the state alive. Asp .net stores the sessions in different ways. By default the session is stored in the asp .net process. You can always configure the application so that the session will be stored in one of the following ways
[1] Session State Service
There are two main advantages of using the State Service. First the state service is not running in the same process as the asp .net application. So even if the asp .net application crashes the sessions will not be destroyed. Any advantage is sharing the state information across a Web garden (Multiple processors for the same computer).
Lets see a example of the Session State Service.
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:55455" sqlConnectionString="data source=127.0.0.1;user id=sa;password='' cookieless="false" timeout="20"/>
The attributes are self explanatory but I will go over them.
mode: This can be StateServer or SqlServer. Since we are using StateServer we set the mode to StateServer.
stateConnectionString: connectionString that is used to locate the State Service.
sqlConnectionString: The connection String of the sql server database.
cookieless: Cookieless equal to false means that we will be using cookies to store the session on the client side.
[2.] SQL Server
The final choice to save the session information is using the Sql Server 2000 database. To use Sql Server for storing session state you need to do the following:
Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store the session.
You web.config settings will look something like this:
<sessionState mode = "SqlServer" stateConnectionString="tcpip=127.0.0.1:45565" sqlConnectionString="data source="SERVERNAME;user id=sa;password='' cookiesless="false" timeout="20"/>
SQL Server lets you share session state among the processors in a Web garden or the servers in a Web farm. Apart from that you also get additional space to store the session. And after that you can take various actions on the session stored.
The downside is SQL Server is slow as compared to storing session in the state in process. And also SQL Server cost too much for a small company.
[3] InProc:
This is another Session State. This one is mostly used for development purposes. The biggest advantage of using this approach is the applications will run faster when compared to other Session state types. But the disadvantage is Sessions are not stored when there is any problem that occurs with the application, when there is a small change in the files etc., Also there could be frequent loss of session data experienced.
Error Handling:
<customErrors mode = "On">
<error statusCode = "404" redirect = "errorPage.aspx" />
</customErrors>
Security:
The most critical aspect of any application is the security. Asp.net offers many different types of security method which can be used depending upon the condition and type of security you need.
[1] No Authentication:
No Authentication means "No Authentication" :) , meaning that Asp.net will not implement any type of security.
[2] Windows Authentication:
The Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. If you like to see that what windows user is using the Asp.net application you can use:
User.Identity.Name;
This returns the DOMAIN\UserName of the current user of the local machine.
[3] Passport Authentication:
Passport Authentication provider uses Microsoft's Passport service to authenticate users.
[4] Forms Authentication:
Forms Authentication uses HTML forms to collect the user information and than it takes required actions on those HTML collected values.
In order to use Forms Authentication you must set the Anonymous Access checkbox checked. Now we need that whenever user tries to run the application he/she will be redirected to the login page.
<authentication mode="Forms">
<forms loginUrl = "frmLogin.aspx" name="FAutho" timeout="1"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>