Secure your Web pages with custom authentication

by Phillip Perkins | Aug 09, 2005 7:00:00 AM

Tags: Web servers, Microsoft Windows, Web browsers, Digest Authentication, Phillip Perkins, Web server, Web, authentication, HTTP Status, NTLM, header, HTTP, server, Basic Authentication, Web Development Zone Newsletter

0 comment(s)

Takeaway: For more control over your authorization protocol, you can set the HTTP status of the response and parse the information as you receive it. In this article, Phillip Perkins explores authentication mechanisms in HTTP.

If you want to secure your Web pages, you would probably set the Web server's security. Then, the Web server will recognize the security restrictions and challenge the requesting client for credentials.

The Web server is actually just sending a 401 response code. It's the client's (i.e., the browser's) responsibility to send a response to the authorization challenge. You can expect browsers to handle this functionality seamlessly. But if you want more control over your authorization protocol, you can set the HTTP status of the response and parse the information as you receive it.

A 401 HTTP response code is a feedback mechanism that tells the client that authentication information is required to view or parse the file in question. The response code is an HTTP header called Status. Once you set the Status code, the browser should take care of the rest. In ASP, this is the code for setting the Status code:

Response.Status = "401 Unauthorized"

You must set the Status before adding any information to the Response buffer. In PHP, you set the Status through the header() function:

header("Status: 401 Unauthorized", true);

Once you challenge the client, you need to send it a method by which it can answer the challenge. The method you should send is the WWW-Authenticate HTTP header, which has four ideal values that you can specify: Basic, Digest, NTLM, and Negotiate.

Basic authentication informs the browser to pass credentials to the server as plain text. This isn't very safe unless it's within the context of SSL.
Digest authentication challenges the client using a nonce value, which is a server-specified string value. The client returns a checksum of the username, password, the nonce value, the HTTP verb, and the requested URI.
NTLM is a Windows-specific challenge-response mechanism. You'll find this on IIS servers, although Mozilla can also answer NTLM challenges.
Negotiate is an authentication mechanism based on Kerberos for Windows 2000 and greater. If the OS is less than Windows 2000, Negotiate defaults to NTLM.

For simplicity, let's assume that you're only interested in Basic authentication. This value is the easiest to program, and it allows me to show you how to implement this functionality to a further degree.

In the following example, you'll authenticate the client through Basic authentication; however, you'll go one step further and specify that the client can only authenticate on Tuesdays. Here's the ASP code:

<%@ Language=VBScript %>
<%
Option Explicit
Response.Buffer = True
Response.Expires = -1

If Request.ServerVariables("LOGON_USER") = "" Then
    Response.Status = "401 Unauthorized"
    Response.AddHeader "WWW-Authenticate","NTLM"
    Response.End
Else
    If Weekday(Now()) <> 3 Then
        Response.Status = "401 Unauthorized"
        Response.AddHeader "WWW-Authenticate","NTLM"
        Response.End
    End If
End If
%>
<html>
<head>
<title>Success!</title>
</head>
<body>
You made it!
</body>
</html>

By checking the LOGON_USER HTTP environment variable, you can tell if the user has been authenticated by IIS. If this variable was blank, the user couldn't be authenticated with the given credentials. Finally, check that the day of the week is a Tuesday. If it isn't, set the status to 401 again, and end the response.

To learn more about authentication mechanisms in HTTP, check out the MSDN Web site.

Keep your developer skills sharp by automatically signing up for TechRepublic's free Web Development Zone newsletter, delivered each Tuesday.

0 comment(s)