Flicks Software

Products

Authentication
Tutorial
Page 3 of 3



Back to index

Authentication using ASP.NET Methods


ASP.NET is similar to tradional .asp authentication in that it is dependent on cookies. ASP.NET does allow the developer more control over configuring different authentication methods.

Those methods include :

  • Forms - Based authentication : uses a cookie for authentication. See the cookie section of this tutorial for more information on cookie-protection.
  • Passport Authentication : requires Microsoft's Passport Authentication.
  • Windows Authentication : a.k.a. integrated Windows authentication

You can find implementation information on ASP.NET here: http://www.asp101.com/articles/cynthia/authentication/default.asp

FORMS BASED AUTHENTICATION

You will want to use forms based authentication with ASP.NET if :

  • You want to use accounts that are separate from Windows accounts.
  • You only need to protect aspx files.

You wont want to use Forms Based Authentication if :

  • You are concerned about attackers exploiting the cookie.
  • You don't want the performance hit associated with resources mapped to Aspnet_isapi.dll.
  • You want to protect all files, not just aspx.

WINDOWS AUTHENTICATION

You won't want to use Windows Authentication if:

  • you expect (don't we all?) a large number of users Having a large number of users becomes a problem because this clutters the NT user database and it becomes very difficult to maintain.
  • larger numbers of NT accounts can impair the speed of the operating system itself!
  • potential security risks: you are elevating a 'mere' web surfer to the status of a full NT user with all that implies. Great care is require in allocating permissions, and a compromised full NT account is not a good thing.

PASSPORT AUTHENTICATION

You want to use Passport Authentication if :

  • You want to allow a "single sign-on" across multiple domains.
You won't want to use Passport Authentication if:
  • You are concerned about being dependent on an external Microsoft resource for the authentication process.


Back to index

Cookie Based Authentication Using A Third Party filter

In essence, cookies are small text files which allow you to (among other things) permit users access to your web content. You can find a great tutorial on cookie based authentication here

Cookie Based Authentication via a third party filter has ALL of the benefits of Third Party Basic Authentication PLUS

  • It allows you to simplify your ASP and ASP.NET code
  • Your ASP code is shorter, so it runs FASTER
  • There is no risk of revealing your source code and datasource locations/passwords
  • AuthentiX also protects ALL files while using cookie based authentication - including HTML , ASP, and .NET related files.
  • You want the high performance that a filter offers
  • You want to be able to add and modify users from ASP/.NET and don't want the ASP/.NET pages to have SysAdmin priviledges
  • You want browser independence
  • You don't want any chance of compromising NT username/password security
You will want to use Cookie Based authentication via AuthentiX if:
  • You are worried about revealing your source code, datasource and their passwords via FrontPage 2000 or similar programs
  • You want the additional speed of cookie based authentication
  • You don't want your users to have to login every time they visit your site


Back to index

Write your own Basic Authentication filter

Writing your own Basic Authentication filter is an option if you have the skills, resources and time to do it.

Definitions

  • ISAPI = Internet Server Application Programming Interface

How to write your own Basic Authentication filter

You will need to build a dll that conforms to the ISAPI filter specification and has the following entry points:
  • GetFilterVersion
  • HttpFilterProc
The GetFilterVersion function is the first entry point called by the Internet Information Server. In this function you set the IIS notifications that you want to receive, and any other first time setup tasks.

The HttpFilterProc function is called in response to the notifications set in GetFilterVersion and is where the work of the filter is actually done.

There are several excellent references to help develop an ISAPI filter. Recommended is Que's "Special Edition Using ISAPI", ISBN 0-7897-0913-9 (to which this writer also contributed).

Writing your own Basic Authentication filter is the way to go if

You won't want to write your own Basic Authentication filter if

  • a third party tool like AuthentiX meets all your needs







  • Back to index

    Digest Authentication

    You can use Digest Authentication with IIS to authenticate access to your web content. Digest Authentication works similar to NTLM, with a challenge response protocol. However, Digest Authentication has several weaknesses:

    • It does not provide mutual authentication
    • It does not provide a method for exchanging session keys for data encryption or MAC generation
    • It weakens password storage significantly
    • Passwords must be stored so that the domain controller can decrypt them with reversible encryption, weakening your website security
    • For maximum security, you must place the web server on the same machine as the domain controller. Otherwise, you expose your public web server from the domain controller and open yourself up to serious security risks.

    Digest Authentication is not the ideal solution for administrators concerned about web content security.




    Back to index

    Cookie Based Authentication with ASP pages

    You can use the cookie based session variables of Active Server Pages to capture a username and password from a form, validate the username and password, then set a session variable to indicate the user has correctly logged in.

    Note: AuthentiX V2 and up can protect via cookies, but protects all pages, not just ASP, and you do not need extra code in each page, or in a global app area. ASP solutions will always be slower than filter based solutions like AuthentiX.

    Definitions

    • ASP = Active Server Pages.

    How to use Cookie Based Authentication with ASP pages

    • Create a login page like the following example:

      Login.asp

      <form action="loginNow.asp" method="POST">
      Username: <input type="text" name="username" size="22"> <br>
      Password: <input type="password" name="password" size="22"><br>
      <input type="submit" value="Login Now">
      </form>

    • Create an ASP page to receive and process the results like the following example:

      LoginNow.asp

      <%
      username = Request.Form("username")
      password = Request.Form("password")
      if ("George" <> username) Then
      response.Write("Sorry, incorrect username and password (1)")
      response.End
      End if
      if ("Washington" <> password) Then
      response.Write("Sorry, incorrect username and password (2)")
      response.End
      End if
      Session("username")=username
      %>
      George, you have logged in successfully.
      <a href=protected.asp>Please continue to the protected page</a>

    • In each ASP page to be protected, check the username and password. You could use an include file statement if you had several ASP pages and wanted a single file to do the checking.

      protected.asp

      <%
      username = Session("username")
      if ("" = username) Then
      response.Write("Sorry, you are not logged in.")
      response.End
      End if
      %>
      You have access to this Active Server Page!

    Cookie Based Authentication with ASP pages is the way to go if

    You won't want Cookie Based Authentication with ASP pages if
    • You want to protect all content, not just ASP pages.
    • You are worried about performance. Any reasonably large amount of Active Server Pages can have a significant detrimental effect on the performance of your server. The popularity of products such as XBuilder, which generates static html pages from ASP pages for performance reasons (among others), illustrates this point.
    • Cookie-based systems can be susceptible to spoofing.

    Back to index

    Self-authenticating scripts.

    Self-authenticating scripts usually provide a single URL entry point, with parameters indicating the current state of the session and the content requested. Self-authenticating scripts can be written as ASP, CGI, Win-CGI, or ISAPI dlls, and other variations.

    Definitions

    • ASP = Active Server Pages. The script communicates with IIS via server-variables.
    • CGI = Common Gateway Interface. The script communicates with IIS via stdin and stdout.
    • Win-CGI = Windows Common Gateway Interface. The script communicates with IIS via temporary INI files.

    How to use Self-authenticating scripts

    There are too many variations to show how to create a self authenticating script in this tutorial, however they all share a common means of authenticating.

    When a request comes in and the content to be displayed is protected by a Basic Authentication username and password, the script sends a 401 Access Denied message, indicating the realm, and some html that is displayed to the user when the login attempt fails.

    A regular http reply looks like this:

    HTTP/1.0 200 OK
    Server: Microsoft-IIS/3.0
    Date: Wed, 11 Mar 1999 16:31:52 GMT
    Content-Type: text/html
    Last-Modified: Wed, 18 Feb 1998 22:45:46 GMT
    Content-Length: 1234

    Content: Interesting Stuff

    A 401 Access denied reply looks like this

    HTTP/1.0 401 Access Denied
    Content-type: text/html
    Server: Microsoft-IIS/3.0
    Date: Wed, 11 Mar 1999 16:35:47 GMT
    WWW-Authenticate: Basic realm="Message in Popup"

    Content: You cannot get in!

    Once the script sends a 401 Access Denied message, the browser will pop up a dialog indicating the realm, and invite the user to enter a username and password. The user will not see the access denied content unless the login fails. Some browser keep retrying the pop-up dialog until it succeeds or the users escapes out, others only pop-up three times.

    If the user types in a username and password the browser will send them to the server as a part of the http request header that looks like the following:

    Authorization: Basic cGvcmU6cGRcmU=

    The string "cGvcmU6cGRcmU=" is Base64 encoded.
    The script will ask the server for this header by requesting the server variable HTTP_AUTHORIZATION, and decode it. The resulting string will be in the format username:password and the script can match these against acceptable values in order to determine whether to transmit the content or issue another 401 Denied.

    NB: In IIS4 and above, the HTTP_AUTHORIZATION value may not be returned correctly by IIS. In MMC, select the directory in which the ASP page calling this function resides. If Basic (Clear Text) is off, and NTCR (Integrated Windows Authentication in Windows 2000) is on, then HTTP_AUTHORIZATION will not return the correct value. This problem did not occur in IIS3. Microsoft bug Case Number is SR X980 2166010 644. Recommended workaround is to either

    • turn Basic (Clear Text) off and NTCR off for that directory.OR
    • turn Basic (Clear Text) on and NTCR on for that directory,
    Make sure that Allow Anonymous is checked.

    Self-authenticating scripts is the way to go if

    You won't want Self-authenticating scripts if

    You want protected content in normal directory/file/html format

    You are worried about maintaining the content. Scripts can become fairly complex when the content becomes large, and changes are not easily made. If you have content stored in a database then this can be more flexible, but you have the added complexity and performance hit of interfacing to the database.



    Back to index

    Certificate based authentication.

    Client certificates are an advanced form of authentication, and at this time they are still very much in their infancy with respect to compatibility and ease of use.

    Definitions

    • SSL = secure socket layer.
    • MMC = Microsoft Management Console.

    How to use Certificate based authentication

    Since this technology is still maturing, be sure to have the latest versions of IIS installed on your system.
    • Obtain a certificate from a certificate issuing authority such as Verisign or Thawte. Refer to the IIS documentation on Key Manager.
    • Select a directory you want to protect in the MMC
    • Click on the Secure Communicatations Edit button on the Directory Security property sheet and use the certificate you obtained. Select both Enable Client Certificates and Require Client Certificate
    • Enable client certificates for this resource
    • Issue client certificates for access to this resource.
    There are several good references to help understand and use Client Certificate technology. Some articles that are recommended include:
    "Internet Information Server 4.0 - Security for the Web-Enabled Enterprise" by Nick Evans in the Premier Edition of Security Advisor by Advisor.com publications, and
    "Web Project, Digital IDs" by Jon Udell in the March Edition of Byte magazine. and
    "Issuing digital certificates with Microsoft Certificate Server" section of the IIS Security White Paper by Microsoft.

    Certificate based authentication is the way to go if

    You won't want Certificate based authentication if



    <=== Previous Page

    SPECIAL THANKS TO STEVEN SMITH of ASP ALLIANCE

    By Kevin Flick, Flicks Software
    http://www.flicks.com/

    Copyright © 1998-2005 Kevin Flick
    Revised 2003 Scott Gordon
    Updated 2005

    All rights reserved.
    This document may not be reproduced or distributed in whole or in part without prior written permission from the author.

    Top