Web security

The following is a demonstration of the Web.config file in ASP.NET:

In this case the Web.config file in the folder contains the details of the login, such as three user names and passwords:

<?xml version="1.0"?>
<!-- 
    Note: As an alternative to hand editing this file you can use the 
    web admin tool to configure settings for your application. Use
    the Website->Asp.Net Configuration option in Visual Studio.
    A full list of settings and comments can be found in 
    machine.config.comments usually located in 
    \Windows\Microsoft.Net\Framework\v2.x\Config 
-->
<configuration>

    <system.web>
        <!-- 
            Set compilation debug="true" to insert debugging 
            symbols into the compiled page. Because this 
            affects performance, set this value to true only 
            during development.
        -->
        <compilation debug="true"/>
        <!--
            The <authentication> section enables configuration 
            of the security authentication mode used by 
            ASP.NET to identify an incoming user.   
        -->
        <authentication mode="Forms">
            <forms name="testing" loginUrl="login.aspx" protection="All" timeout="30" path="/">
                <credentials passwordFormat="Clear">
                    <user name="fred" password="pass1"/>
                    <user name="bert" password="pass2"/>
                    <user name="napier" password="pass"/>
                </credentials>
            </forms>
        </authentication>
        <authorization>
            <deny users="?"/>
        </authorization>   
        <!--
        <authentication mode="Windows"/>
        -->
        <!--
            The <customErrors> section enables configuration 
            of what to do if/when an unhandled error occurs 
            during the execution of a request. Specifically, 
            it enables developers to configure html error pages 
            to be displayed in place of a error stack trace.

        <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
            <error statusCode="403" redirect="NoAccess.htm" />
            <error statusCode="404" redirect="FileNotFound.htm" />
        </customErrors>
        -->
        <pages validateRequest="false" />
    </system.web>
</configuration>

and the code on the button event on the Login form is:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

public partial class login : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {

    }
    protected void Button1_Click(object sender, EventArgs e)
    {
        // authenticate user: this sample authenticates 
        // against users in your app domain's web.config file
        if (FormsAuthentication.Authenticate(UserEmail.Value,
                                             UserPass.Value))
        {
            FormsAuthentication.RedirectFromLoginPage(UserEmail.Value,
                                                      PersistCookie.Checked); 
        }
        else
        {
            lblResults.Text = "Invalid Credentials: Please try again";
        }
    }
}

Details

The Web.config file is used to defined the security of a Web service, which are XML-based so that the developer can change settings without an application rebuild. It is extensible so that new configuration parameters can be added, along with handlers which consume them. Also, each Web application folder can have its own Web.config file, which defines the security for the application folder and all its children (which inherit the configuration information from their parents). The security configuration is initially loaded when the application is first used, and then cached for all future accesses. Any subsequent changes are automatically detected, and applied. An important security factor is that the Web.config file cannot be viewed through a Web browser, as shown in Figure 1.

Figure 1 Security

The main configuration settings are contained within the <configuration> and </configuration> root tags. These include:

· <authentication />. This tag is used to define the authentication policies of the application. It can be set to Windows, Forms, Passport, or None. For example <authentication mode="Windows" />.

· <authorization />. This tag is used to define the authorization polices of the Web service. The users attribute can be set with wildcards such as * (for everyone and anonymous) and ? (unauthenticated) wildcards. An example is <allow users="*" />.

· <compilation />. This tag is used to define the compilation language and whether it can be debugged. A true for the debugging option allows the PDB infromation to be inserted into the compiled page. An example is <compilation defaultLanguage="c#" debug="true" /> which sets the default language to C# and enables debugging for the Web service.

· <customErrors />. This tag is used for custom error messages. To enable these, the On or RemoteOnly modes are used, otherwise it is Off. An example is <customErrors mode="RemoteOnly" />.

· <globalization />. This tag is used to defined the globalization settings for a Web service. An example is <globalization requestEncoding="utf-8" responseEncoding="utf-8" />.

· <trace />. This tag is used to define application-level tracing of the Web service, and enables a trace log. A setting of True enable application trace logging. An example is <trace enabled="true" />.

11.1.1 Web service security

The two key elements for securing a Web service are defined by the <authentication /> and <authorization /> tags. For authentication, the authentication providers are defined, along with IIS authentication schemes. The authentication providers are:

· Windows [Default]. With this method, the authentication process uses IIS to authentication the client. Once it has authenticates the client, it passes a security token to the Web service. For example:

· Forms. With this method, the authentication mode uses an HTML log-in form to authenticate the client, which are then passed to the Web server for authentication. On a successful authentication, the server issues a cookie to the client, which is then used by the client to access the Web service. Any service which does not have a cookie, will redirect the user to a login screen. An example to define the form is:

</authentication>

· Passport. With this method, a centralized authentication service is used to define access, with a single logon and profile services for member sites. This is typically used to register sites with a single passport, and grants a site-specific key. This key is then used to encrypt and decrypt query strings between the site and the logon server. An example to define the password authentication is:

· None. This is used when there is no authentication, or where there us customized authentication. An example to define this is:

Along with this it is possible to define authentication for specific users and roles.

For authorization, specific users and roles can be defined for given access, which is a specific allow or deny.

For example to disallow a user named “Fred” and allow the Administrator group:

</authorization>

Along with this a wildcard can be used for the roles and users. The * defines everyone and the ? for anonymous users, such as:

</authorization