In a previous article, we covered the first Web application security framework (WASF), database lookup. The database lookup model is by far the most common on the Internet. Every time you log on to a Web mail client or check your online bank account, you’re probably using the database lookup method. This method is widely used because it’s the easiest to manage and maintain for the company running the site. In fact, it’s primarily up to the individual users to administer their information.

This article will take a look at the second WASF: OS level authentication. As you’ll see, this model is the simplest method for users, since it requires little to no administration on their part. There’s no sign-up page or login page. The Web site knows who you are the second you hit the site.

Previous articles in the series

You can catch up from the beginning of the series by reading this introductory article.

What is it?
The OS level authentication framework is a method for authenticating and authorizing a user with credentials supplied by the operating system of the user’s computer. This methodology is primarily used for internal Web applications and corporate intranets.

The belief behind this system is reuse. In order for a person to log on to a network, the network administrator has to set up a separate account for each individual. Therefore, if you know each user already has a unique identifier, why force them to devise another?

The obvious benefit of this method is the elimination of account management by the user. Since they have no control over network user management, they have little to no control of their account. The only thing they usually have control over is their password, and sometimes not even that.

The Web development team is another group whose lives are simplified with this method. They can concentrate more on the content and less on user management pages, such as sign-up or password-change pages.

How it works
At the most basic level, here’s what transpires in the OS level authentication model. When the browser sends its HTTP request for the Web page, there is a header in that call. A variety of information is passed in that header, such as browser type and the file being called. One item that can be sent in this header is the network login ID of the user. The Web server, if configured correctly, can then check that ID against its list of authorized network IDs. If the user’s ID is found, the user can view the page. If the user’s ID is not found, the server simply does not send the page requested. Instead, the Web server will send them an error page in return, notifying the user that they do not have the rights to view that page.

The tough thing about this method is that the network administrators have a ton of administration duties for the users of the site. The users have no area where they can sign up and request access as needed. Instead, they must rely upon the network security team to properly administer their accounts. The nice thing, though, is that you know who every single user of your site is. You know the distinct groups they make up, and therefore can create the site with these groups in mind.

How secure is this model? By definition, it appears to be very secure. If a user doesn’t have a network login, there will be no chance that they can view the Web site. You have prior knowledge of people’s network IDs, and can even customize content just for them. The only drawback is that the average user is not very careful with their logon IDs or passwords. Many will log on to the network, then leave their desks without locking their computers. Or worse, the user will write a network password on a sticky note attached to the monitor. This allows for malicious users to compromise network security and gain access to restricted sites.

The primary method for implementing this security framework is by configuring your Web server. There is usually a setting that needs to be turned on to notify the client’s browser that the Web server is expecting a set of OS level credentials. In order for this to work on some systems, you need to turn off the function that allows anonymous access. This may sound a bit counter to the standard Web experience, which is based on anonymous access, but the files and content sitting on the particular Web servers utilizing this method are probably not meant for anonymous users to see anyway.

The implementation can vary in the type of systems used, but no matter the hardware, OS, or Web server, it’s all implemented in a way very similar to the one described above. Some administrators choose to integrate the security with the default network domain. Other administrators may choose to create a separate domain for users who merely need access to certain servers and not the entire network. If the administrator chooses the former, the users may already have logins, and so his or her work is finished. However, with the latter choice, the administrator will have to set up each user account on the network prior to their first login.

Quick and simple
The fact that OS level authentication is tied to network security can be a blessing or a curse. Its security in concept is very thorough on paper. However, because of some individuals’ lax security practices, what should be secure can instantly become insecure. Overall, though, OS level authentication could be a quick and simple way for you to ensure that only the proper people can access a particular Web server and its content.

The next article in this series will discuss the third type of WASF, digital certificates. You’ll learn when you should, or can, use them and why. As you’ll learn, their applications are costly, but when the situation calls for digital certificates, their power quickly justifies that cost.