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 have special requirements, and commissioning a custom enhancement to a third party Basic Authentication filter is not an option. you have the skills, resources and time. you want to validate against a specific or proprietary type of datasource, such as flat-file, or your own database. You won't want to write your own Basic Authentication filter if you have a short deadline you do not have the skills or resources required Basic Authentication is not secure enough for your purposes you want all accounts of every type in one userbase, specifically the NT user account database, for administrative reasons. 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 are happy coding your own solution in VBScript, and you only have a few asp pages to protect. You don't mind excluding those who cannot or will not accept cookies. You don't have gif/jpeg/pdf or other non-ASP content, so you are not concerned about someone else creating web-pages linking directly to your non-ASP protected content. 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 have the skills, resources and time to do it. You want to generate your content in a single program 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 want a high degree of certainty of the identity of the users accessing your site You accept the need for SSL and don't mind paying the performance penalty. You already have a certificate or you don't mind paying for one and setting it up. You won't want Certificate based authentication if The process of issuing a client certificate is too complex and intimidating for both you and your users You do not want the performance hit of having all protected information exchanged via SSL <=== 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