Java Web Hosting for Developers

Secure Sockets Layer (SSL) S-HTTP seems to have been engulfed in the 1995 Netscape tidal wave. Unwilling to wait for widely accepted httpd security standards to evolve (as it was with HTML as well), Netscape Communications Corporation developed its own SSL encryption mechanism. SSL occupies a spot on the ISO seven-layer network reference below that of the httpd protocol, which operates at the application layer. Rather than developing a completely new protocol to replace httpd, SSL sits between httpd and the underlying TCP/IP network protocols and can intervene to create secure transactions. Netscape makes the technical details of SSL publicly available. In addition, C-language source code for a reference implementation of SSL is freely available for noncommercial use. The Netscape Navigator Web browser has built-in SSL support, as does the Netscape Commerce Server; the Netscape Communications Server does not support SSL. Given Netscape’s share of the Web browser market, it’s hard to see how S-HTTP has much of a chance at becoming widely available. With the exception of ncSA Mosaic, most other Web browsers have-or have promised-SSL support. Some of them are Spry’s newer product, Internet in a Box, Mosaic in a Box for Windows 95, and Release 2 of Microsoft’s Internet Explorer for Windows 95 and the Macintosh. By the time you read this book, all of these packages might have completed their SSL implementations. Note Even though a browser might support secure transactions using SSL or S-HTTP, no transactions are actually secure except those between the browser and a compatible Web server. Thus, using Netscape, for example, won’t provide any security unless you’re also using the Netscape Commerce Server. It’s also important to note that simply using a proxy service (that is, passing Web services through network firewalls) does not imply secure transactions unless both the proxy server and the destination server do. As noted in the preceding section, the Netscape Commerce Server supports the company’s SSL security mechanism. Other packages that support SSL include the Secure WebServer package from Open Market, Inc., (http://www.openmarket.com/), which also supports S-HTTP, and IBM’s Internet Connection Secure Server, which runs under IBM’s UNIX, AIX Version 4, and OS/2 Warp. (Evaluation copies of Secure WebServer for several UNIX systems are available at the Open Market Web site.) Both Secure WebServer and Internet Connection Secure Server are based on Terisa Systems, Inc.’s SecureWeb Client and Server Toolkit. This package provides source code for developers building secure Web servers and browsers. The Terisa Toolkit supports both SSL and S-HTTP. For more information about the package, visit Terisa’s Web site at http://www.terisa.com/. Open Market’s promotional announcements about Secure WebServer state that the package supports secure transactions through Internet firewalls, but no details on just how this works are provided. The Common Gateway Interface (CGI) and Intranet Security CGI is the mechanism that stands behind all the wonderful, interactive fill-in forms you’ll want to put on your intranet. Your customers might demand these kinds of intranet resources. CGI-BIN scripting is susceptible to security problems, so do your scripting carefully to avoid such problems. You can minimize much of your risk of security breaches in CGI-BIN scripting by focusing on one particular area: Include in your scripts explicit code for dealing with unexpected user input. The reason for this is simple: You should never trust any information a user enters in a fill-in form. Just because, for instance, a fill-in form asks for a user’s name or e-mail address, there is no guarantee that the user filling in the form won’t put in incorrect information. Customers make typographical errors, but probing crackers, even those inside your organization, might intentionally enter unexpected data in an attempt to break the script. Such efforts can include UNIX shell meta-characters and other shell constructs (such as the asterisk, the pipe, the back tick, the dollar sign, and the semicolon) in an effort to get the script to somehow give the user shell access. Others intentionally try to overflow fixed program text buffers to see if the program can be coaxed into overwriting the program’s stack. To be secure, your CGI-BIN scripts have to anticipate and deal safely with unexpected input.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

Other problems inherent with CGI-BIN scripts include l Calling outside programs, opening potential security holes in the external program. The UNIX sendmail program is a favorite cracker target. Using server-side includes in scripts, which dynamically generate HTML code. Make sure user input doesn’t include literal HTML markup that could call a server-side include when your script runs. l l Using SUID scripts are almost always dangerous, whether or not in a CGI-BIN context. Paul Phillips maintains a short but powerful list of CGI-BIN security resources on the Web. Check out http://www.cerf.net/~paulp/cgi-security, where you’ll find a number of documents spelling out these and other risks of CGI-BIN scripting. For an extensive list of general CGI-related resources, go to Yahoo!’s CGI page, at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/CGI_Common_Gateway_Interface/index.html. Your Intranet and the Internet Is your intranet accessible from the Internet? If so, all of the security problems of the Internet are now your intranet’s problems, too. Throughout this book, an implicit assumption has been made that your intranet is private to your organization. You can, however, connect safely to the Internet and still protect your intranet. You can even use the Internet as a means of letting remote sites in your company access your intranet. First, look at some Internet security basics. Firewalls It’s a fact of Internet life that there are people out there who want to break into other people’s networks via the Internet. Reasons vary from innocent curiosity to malicious cracking to business and international espionage. At the same time, the value of the Internet to organizations and businesses is so great that vendors are rushing to fill the need for Internet security with Internet firewalls. An Internet firewall is a device that sits between your internal network and the outside Internet. Its purpose is to limit access into and out of your network based on your organization’s access policy. A firewall can be anything from a set of filtering rules set up on the router between you and the Internet to an elaborate application gateway consisting of one or more specially configured computers that control access. Firewalls permit desired services coming from the outside, such as Internet e-mail, to pass. In addition, most firewalls now allow access to the World Wide Web from inside the protected networks. The idea is to allow some services to pass but to deny others. For example, you might be able to use the Telnet utility to log into systems on the Internet, but users on remote systems cannot use it to log into your local system because of the firewall. Here are a couple of good general Web resources about Internet firewalls: l Marcus Ranum’s Internet Firewalls Frequently Asked Questions document at http://www.greatcircle.com/firewalls/info/FAQ.html Kathy Fulmer’s annotated list of commercial and freeware firewall packages (with many hyperlinks to firewall vendor Web pages) at http://www.greatcircle.com/firewalls/vendors.html l If your company is also connected to the Internet, you’ll want to know how to make sure your intranet isn’t generally accessible to the outside world. You learned earlier in this chapter about denying access to your Web server using hostname and IP address authentication, but the fact that IP addresses can be easily spoofed makes it essential that you not rely on this mechanism as your only protection. You’ll still want to rely on an Internet firewall to protect your intranet, as well as all your other network assets. Moreover, unless your corporate network is not connected to the outside world at all, you’ll want to ensure the security of your other intranet services, including not only your Web servers, but also your FTP, Gopher, Usenet news, WAIS, and other TCP/IP network services.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

GroupFile /usr/local/etc/httpd/group GetMask @*.personnel.mycompany.com, @123.45.67.*, personnel } As with the ncSA example, this one applies hostname/IP address access control first (since it appears on the GetMask line first) and then username/password authentication. Both rules must be satisfied before access is permitted. To further restrict access, you’ll need to develop LACFs for individual directories and subdirectories. As noted earlier, the CERN/W3 LACF file’s format is completely different from that of the server’s GACF. Here’s one (note the file must be named .www_acl) that can be placed in the personnel/executive directory to limit access to the subdirectory to user anne, and only from a specific hostname/IP address: * : GET : anne@annspc.personell.mycompany.com, ann@123.45.67.89 This simple file has just one rule. (The rule is usually a single line, with colon-separated records, but it can be wrapped, as shown above, after a comma.) No one other than the user anne (who must give a password under the rule in the previous example) can access any files in the personnel/executive directory. Moreover, anne must be accessing the files from her normal pc to be granted access, even if she gives the correct password. For more information on CERN/W3 LACFs, check out the online documentation at http://www.w3.org/pub/WWW/Daemon/User/Admin.html. Secure/Encrypted Transactions You can further enhance security on your intranet by encrypting Web transactions. When you use an encryption facility, information submitted by customers using Web fill-in forms-including usernames, passwords, and other confidential information-can be transmitted securely to and from the Web server. There are a wide range of proposed or partially implemented encryption solutions for the Web, but most are not ready for prime time. Of the several proposed methods, only two have emerged in anything like full-blown form. Let’s look at the Secure HTTP (S-HTTP) and Secure Socket Layer (SSL) protocols in this chapter. Unfortunately, the two protocols are not compatible with each other. Worse, Web browsers and servers that support one method don’t support the other, so you can reliably use one or the other only if you carefully match your Web server and customers’ browsers. Secure HTTP (S-HTTP) S-HTTP was developed by Enterprise Integration Technologies and RSA Data Security, and the public S-HTTP standards are now managed by CommerceNet, a nonprofit consortium conducting the first large-scale market trial of technologies and business processes to support electronic commerce over the Internet. (For general information on CommerceNet, see http://www.commerce.net/.) S-HTTP is a modified version of the current httpd protocol. It supports l User and Web server authentication using Digital Signatures and Signature Keys using both the RSA and MD5 algorithms. l Privacy of transactions, using several different key-based encryption methods. l Generation of key certificates for server authentication. EIT has developed modified versions of the ncSA httpd server and ncSA Mosaic (for UNIX and Microsoft Windows), which both support S-HTTP transactions. Although the licensing terms allow for ncSA to fold EIT’s work into its free httpd server and Mosaic browsers, there’s been no public indication of ncSA’s plans to do so. Meanwhile, the CommerceNet secure ncSA httpd server and Mosaic browser are available only to members of CommerceNet. You’ll find information about both packages, including full-text user manuals, at the CommerceNet home page http://www.commerce.net/.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services

Tip Netscape DCFs in lower-level directories take precedence over the rules in a DCF in a higher-level directory. Thus, by creating a .nsconfig file in the personnel/executive subdirectory, you can limit access to files in that directory to the user anne, as you did earlier in this chapter. Such a DCF might look like this: RequireAuth dbm=webusers userpat=anne userlist=anne RestrictAccess method=HTTP method-type=allow ip=123.45.67.89 dns=annspc.personnel.mycompany.com You can enable Netscape DCFs using fill-in forms similar to those shown earlier for setting up hostname/IP address access control. For example, you can enable a DCF for a given server resource, and the graphical interface will create a skeleton .nsconfig file. However, you’ll need to use a text editor to add your own detailed access control and other directives. Combined Authentication in the ncSA Servers Combining username/password and hostname/IP address authentication in the ncSA httpd servers is fairly simple. You’ll extend the rules in the sections of either the GACF or LACF. Here’s the now-familiar personnel example, modified to combine the two access control methods: AuthType Basic AuthName Personnel Only AuthUserFile /usr/local/etc/httpd/userpw AuthGroupFile /usr/local/etc/httpd/ourgroup order deny,allow deny from all allow from personnel.mycompany.com allow from 123.45.67 Require group personnel As you can see, all you needed to do was to pull in both of the two sample methods shown in the earlier ncSA examples. Notice that order counts in the section. Here, the hostname/IP address access control rules are applied first (using the deny and then allow sequence). After those rules are satisfied, the user is prompted for a password as the username/password authentication is applied. Based on this example, it’s easy to modify this rule for an LACF in the personnel/executive subdirectory, simply by replacing Require group personnel with Require user anne. Combined Authentication in the CERN/W3 Server The CERN/W3 Server is similarly capable of combining username/password and hostname/IP address authentication. Here, you’ll modify the GetMask directive in your GACF. Again, here is the modified personnel example, this time limiting access using both methods: Protection Personnel { AuthType Basic Passwordfile /usr/local/etc/httpd/passwd

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

your GetMask is a good idea; there’s nothing like having the boss’s brand-new PowerMac being denied access to your intranet’s Web server on his very first try because its DNS entry hasn’t been made by the network operations staff yet. Hostname/Address Authentication in the Netscape Server As with most aspects of Netscape Communications Server administration, you can set up hostname/IP address access control using a graphical interface. Start up the Administration Manager and select Restrict Access From Certain Addresses. This opens a document with extensive instructions for setting up access restrictions. You’ll find fill-in boxes in this document for hostname/IP address restrictions. Figures 5.6, 5.7, and 5.8 show the essential parts of this form. You have all the same choices here for restricting access that you saw in the ncSA and CERN/W3 httpd servers. Figure 5.6 : Netscape Communications Server Host restriction (Part 1). Figure 5.7 : Netscape Communications Server Host restriction (Part 2) The first step is to select what Netscape calls a resource to which you’ll apply hostname/IP address restriction. For this purpose, a resource can be the entire Web server tree, a particular part of it, or one or more individual files. Clickable buttons (as shown at the top of Figure 5.6) enable you to select the resource you want. In this example, your resource would be the /usr/local/web-docs/personnel subdirectory of your httpd server tree. After you’ve selected your resource, scroll down the form to the headline What To Protect. (See Figure 5.7.) Here, you’ll find two important choices. You can simply accept the default of protecting everything in the selected resource. Or you can specify a wildcard filename pattern to match the files you want to protect. Notice the hypertext link labeled wildcard pattern, which takes you to a detailed document describing how wildcard pattern-matching works in the Netscape servers. (Essentially, it’s standard UNIX shell filename expansion, but has some additional features.) For the purposes of the example, you need not enter anything, because you’re going to accept the default restriction to all files and directories in the personnel resource. However, you could have entered the wildcard pattern for the files to which you wanted to apply your hostname/IP address restrictions in the boxed and labeled Pattern of files to protect. The Addresses to allow section, which starts in Figure 5.7 and ends in Figure 5.8, tells you how to enter hostnames and IP addresses. Figure 5.8 : Netscape Communications Server Host restriction (Part 3) As with filenames, you can enter either specific individual hostnames or IP addresses, or wildcard patterns that match multiple hosts. The Hostnames to allow and IP addresses to allow boxes are shown in Figure 5.8 with the personnel example filled in. The bottom of Figure 5.8 shows how you can set up a custom message to users who try to access restricted resources, giving them a reason for the denial of their request. You need not use this, but it can be friendlier than the generic Not Found message most httpd servers return. Here, I’ve set things up so the contents of the file /usr/local/web-docs/private.txt will be returned. This file could explain politely, for example, that access to personnel resources on the Web server is limited to the Personnel Department. After you finish the form, scroll all the way to the bottom (not shown in Figure 5.8) and click Make These Changes to apply your restrictions. An Important Warning About Hostname/IP Address Authentication All of the Web server software described in this chapter trustingly accepts the word of a requesting computer when it sends its IP address. Verification of this information is not possible. It’s relatively easy for a user to change the hostname/IP address of a UNIX system, and laughably easy to change that of a pc or Mac. A curious, mischievous, or malicious person can reconfigure his computer to impersonate someone else’s simply by changing the IP address of his own. Although this is an overall network security issue, not specifically one for your intranet, it’s important you know about it because it can affect the security of your access controlled documents. Security-minded network administrators can use special hardware and software to prevent this sort of IP spoofing, but for

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

your intranet, you’ll probably want to combine hostname/IP address authentication with username/password authentication, as outlined in the following section. Combined Authentication Now that you understand how username/password and hostname/IP address authentication work separately, consider how you can combine the two to beef up your access control. Begin with the Netscape Communications Server. Combined Authentication in the Netscape Server Netscape’s scanty $40 documentation for the Communications Server doesn’t address this subject directly, but you can infer from it how to implement combined username/password and hostname/IP address authentication. As you learned earlier, the Netscape server uses one or more user databases to store usernames and passwords, and you can apply access control limits based on both individual usernames and on group membership. Also, the Netscape server can restrict access by hostname/IP address, as described in the previous section. Although the Netscape Communications Server manual and its essentially identical online help describe these two methods as an either/or choice, it would appear that applying both kinds of access control to a single resource would result in both methods being applied. In other words, you can l Define a set of users, such as the sample personnel group I’ve used, in the Netscape user database. Apply username/password authentication, such as to the personnel resource, limiting access to the members of the personnel group in the user database. l Apply hostname/IP address restrictions, such as to the same personnel resource, limiting access to those computers in the personnel subdomain (or even to the individual computers of the members of the personnel group). l Because the documentation doesn’t say what happens in such a situation, including whether there is an order of precedence in the testing of the access control rules, you should very carefully check how things work when you set up intersecting access control rules of this sort. For example, it isn’t clear which rule would be applied first. If the username/password authentication rule goes first, the user will be prompted for a username and password. The hostname/IP address rule would then deny access to even authenticated users. Applying the hostname/IP address rule first, however, will correct this problem. Fortunately for those who want to have their access control rules perform exactly as they want them to, Netscape provides another means of access control, using Dynamic Configuration Files (DCFs). You can think of Netscape’s DCFs as what I’ve called LACFs in this chapter-access control files that apply to a single directory or subdirectory on your Web server. Normally named .nsconfig (note the leading period in the filename), DCFs are organized into discrete sections with HTML-like markup. Each section is marked off by the tags and , in between which are access control and other rules that apply to the files specified. You can do many things with Netscape DCFs; here’s an example that replicates the combined username/password and hostname/IP address access control to the personnel section of the example Web server: RequireAuth dbm=webusers userpat=”anne|joe|jerry” userlist=”anne,joe,jerry” RestrictAccess method=HTTP method-type=allow ip=123.45.67.* dns=*.personnel.mycompany.com This DCF, which goes in the top level of the /usr/local/web-docs/personnel directory, applies to all files and subdirectories in that directory tree. It requires username/password authentication, limiting access to users anne, joe, and jerry listed in the Netscape user database named webusers. It further limits access by both numerical IP address and symbolic hostname, both using wildcards. Notice that it’s not necessary to specify both allow and deny rules; Netscape’s server takes a more conservative approach to access restrictions than do ncSA and CERN/W3.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

way to evaluate your implementation is to follow the actual order in which the directives appear in the file, but it’s easy to make mistakes with this approach. Instead, ncSA httpd uses the order directive so you can explicitly instruct that your directives be processed in the order you want. The example uses order deny,access, indicating all incoming requests are to be tested against the deny directives first and then tested against the allow directives. In the example, you set up a general deny rule and then make exceptions to it. The order directive can also be turned around, with allow rules processed first. Using this sequence, you can make your server generally available and then add selective denials. For example: order allow,deny allow from all deny from .mycompetitor.com Here, you’re granting access to your server to everyone except your competitor. For more information about hostname/IP address authentication, see the ncSA httpd server documentation on the Developing Intranet Applications with Java CD-ROM, or the authentication tutorial at ncSA’s Web site, http://hoohoo.ncsa.uiuc.edu/docs/tutorials/. Hostname/Address Authentication in the CERN/W3 Server You can also impose hostname/IP address access control with the CERN/W3 httpd server. Although you can accomplish the same ends as with the ncSA server, the method of doing so is different, and the access control file formats are different. As you’ll recall from the earlier username/password authentication, the CERN/W3 httpd server uses protection rulesets in the GACF or LACF. I’ll modify the earlier example in which you limited access to the personnel portion of your Web server by group name to illustrate hostname/IP address authentication. For purposes of this example, I’ll assume that your company’s TCP/IP network domain is subdivided along operational lines and that there is a personnel subdomain, all of the computers in which have IP addresses beginning with 123.45.67. Protection Personnel { AuthType Basic Passwordfile /usr/local/etc/httpd/passwd GroupFile /usr/local/etc/httpd/group GetMask @*.personnel.mycompany.com,@123.45.67.* } As you can see, the only thing changed about this ruleset is the GetMask line. In the earlier example, I used GetMask to limit access based on membership in a defined group of usernames, personnel. Here, I’ve done access control limitation in two ways. First, I specified an sub-domain name (personnel.mycompany.com). Second, the rule contains a numerical IP address family. In both cases, I’ve used a special wildcard syntax; note the use of both the @ symbol and the asterisk (*). You can think of the string @*.personnel.mycompany.com as meaning any user at any computer in the personnel subdomain. Similarly, @123.45.67.* refers to any user at any computer with an IP address beginning with 123.45.67. Actually it was not needed. You might be wondering why, since all computers in the personnel subdomain have IP addresses in the 123.45.67 family, I’ve included both rules. I did this for a couple of reasons. The first is to show that you can use either symbolic host/domain/subdomain names or numerical IP addresses. The second reason is a more technical one. In some cases, your httpd server won’t be able to resolve the hostname of a computer making a request for a document from the numerical IP address it receives in the browser request. The reasons for this inability vary, but they usually involve out-of-date or inaccurate DNS information. In growing networks, newly networked computers might not get added to the database promptly. Errors in DNS configuration, such as misspelled hostnames, can also result in unresolvable hostnames. To be safe, placing both symbolic host/domain name and numerical IP address information in

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

User passwords are transmitted over your network by most Web browsers in a relatively insecure fashion. It is not terribly difficult for a user with a network snooper running to pick out the httpd network packets containing user passwords. Although the passwords are not transmitted in clear text, the encoding/encryption method is a very old and widely used one. Every UNIX system, for example, has a program (uudecode) that can decode the encrypted password in a captured httpd packet. If you believe this may be a problem on your intranet, you’ll want to consider the secure Web servers and browsers that encrypt user-transmitted data, as discussed in the section titled “Secure/Encrypted Transactions,” later in this chapter. Authentication Based on Network Hostname or Address All the Web servers discussed in this chapter provide an additional authentication method, using the TCP/IP hostname or numerical network address of customer workstations or pcs as access criteria. As you’ll learn in later chapters, in the context of CGI-BIN programming, every Web browser request for a document or other intranet resource contains the numerical IP address of the requesting computer. Servers look up hostnames using these addresses and the Domain Name Service (DNS). You can set up rules in your GACFs and LACFs based on either of these, making a considerable amount of fine-tuning possible. Hostname/Address Authentication in the ncSA Servers Because the format of the ncSA access.conf file is still fresh in your mind from the last section, look at this one first in the context of hostname/network address authentication. You’ll place your rules for this sort of authentication within the and tags of the server’s GACFs or LACFs sections. Do this with several new access control directives, including l Order, which specifies the order in which the other directives in the file are to be evaluated. l Allow, which permits access based on a hostname or IP address. l Deny, which denies access based on a hostname or IP address. Here’s a simple example limiting access to the personnel subtrees of your Web server. (The opening and closing tags have been left off so as to cut right to the chase.) For purposes of this example, I’ll assume your company’s TCP/IP network domain is subdivided along operational lines and that there is a personnel subdomain in which all of the computers have IP addresses beginning with 123.45.67. order deny,allow deny from all allow from personnel.mycompany.com allow from 123.45.67 In plain English, this example rule says, “access is denied to all hostnames and IP addresses except those in the subdomain personnel.mycompany.com and those in the numerical IP address family 123.45.67.” Notice that both the subdomain name and IP address family are wildcards that might match many computers; you can also use individual hostnames or addresses for even finer-grained control. As you can see, I’ve used each of the three directives listed. You might wonder why I used both allow and deny statements. The World Wide Web was built with openness in mind, not security. The server therefore assumes, without instructions to the contrary, all directories are accessible to all hostnames/addresses. (This is the same as the username/password authentication about which you learned earlier. In the absence of a username/password requirement, all directories and files are accessible to all users.) Without a deny directive, the rule might just as well not exist. The server assumes, in the absence of a deny directive, all hostnames/addresses are allowed access. Why have any rule at all, then, if all are allowed access? In other words, it makes no sense to have rules with allow directives that don’t have deny directives. Because you must have both deny and allow directives in order to have meaningful access rules, the order in which the rules are evaluated is important. One

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

Require group personnel Here, in the GACF file, you’ve limited access to the top level of the personnel tree of the Web server. Only members of the predefined group personnel (defined in the ourgroup file) are allowed to GET (access) files in the directory tree, and they must provide a valid username and password, verifiable against the encrypted password in the userpw file. Most of the lines in the example are clear, but a couple need a little more explanation. AuthName is just an arbitrary label for your rule; you should put something there that’ll make sense when you read the rule a year from now, and you can use a phrase here. The subsection of the file is the critical section, in which you actually specify who has access. You can also include comments in the file, as indicated by the first two lines, where the # symbol is used. As I’ve noted, you can use LACFs to refine the access rules in your GACF. Here’s an example of an ncSA httpd LACF: a file named .htacces in the personnel/executive subdirectory. See if you can translate its meaning: AuthType Basic AuthName Anne Only AuthUserFile /usr/local/etc/httpd/userpw AuthGroupFile /usr/local/etc/httpd/ourgroup Require user anne You’re right; this rule limits access to the executive subdirectory to a single user: anne. The heart of this rule is the matter between the and tags near the end of the file. Other users, including the other members of the personnel group, are denied access, even if they give a correct password for themselves. A dialog box will demand Anne’s username and password. Notice that this LACF file, which controls access to a single directory (personnel/executive), does not require the opening and closing and tags required in the server’s GACF because there are no subdirectories in this directory. Important Warnings About Username/Password Authentication Unless the access rules change (that is, new LACFs are encountered) as a user moves around on your intranet Web pages (as with the personnel/executive subdirectory in the previous example), he will be prompted only once in his browser session for a username and password. As long as he continues his browser session, he can access all of the files and directories available to him under the most recent access rule-without being prompted again for his password. This is for the sake of convenience; customers shouldn’t have to repeatedly provide their usernames and passwords at each step of the way when the access rule hasn’t changed. However, this situation has important ramifications if you follow it logically. Suppose Anne, having authenticated herself to access the executive subdirectory, leaves her Netscape or Mosaic session running, as most of us do. Her privileged access remains open to all the files protected by that one-time, possibly days-old, authentication. If she leaves her workstation, pc, or terminal unattended when she goes to lunch or goes home for the day, without any sort of active screen or office door lock, anyone can sit down and browse the files and directories that are supposed to be limited to Anne’s eyes only. This is a potential security breach, and one that the Webmaster can do little about. This is really no different from a user who leaves his workstation unattended without logging off. Although you can try to educate your customers about such everyday security matters, even though they have very little to do with your intranet, you’ll agree a security breach like this can be potentially harmful to all your work.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services

Like HTML markup, each Directory (the literal word Directory must appear) section is marked off by the access.conf tags and , surrounded with angle brackets. Case is not significant in the word Directory, although it might be in the actual directory name. The directory path here is an absolute pathname and is not relative to either the Web server’s ServerRoot or DocumentRoot directories. If you use /usr/local/etc/htdocs/, for example, you must specify it in full and not just simply use /htdocs. Within each Directory section of the file, you specify one or more options, or configuration commands, which will be applied by the server to the specified directory. There are a number of different options, but we’re concerned here with username/password authentication. Of course, before you can apply a username/password access control, you need to have established users and passwords on your server. Usernames and encrypted passwords are stored in a special httpd password file. ncSA provides a utility program, htpasswd, for creating this file; you’ll find it in the support subdirectory of your ncSA httpd server file tree, and you might need to compile it. The syntax of the htpasswd command is substantially simpler than that of the CERN/W3 htadm command, as are its capabilities. To add a user to your password file or change his password, use this syntax: # htpasswd /path/to/passwordfile username If you don’t already have a password file, you need to modify this command a bit: # htpasswd -c /path/to/passwordfile username The -c argument creates a new password file, so you use it only once. If you use it again, you’ll erase your current password file. You can name your password file anything you like. You can’t remove a user from your password file with the htpasswd command. Instead, you’ll have to hand-edit the password file with a text editor and delete the user’s entry. The format of the file is quite simple, with just two fields in each record, separated by a colon: tkevans:TyWhfX9/zYd7Y The first field is the username. The second field is the encrypted password. Permissions on the password file must be set so as to be readable by the system user under whose userid the httpd server runs (usually, the no-privileges user nobody), so passwords are not stored in clear text. Besides the httpd password file, the ncSA servers also respect a group file in which you can define groups of users. Groups can be treated like individual users with respect to access control, so the group file can add capabilities and save data-entry time. For the most part, syntax of the ncSA httpd group file is exactly the same as that shown earlier in this chapter for the CERN/W3 group file. There is one significant difference in what the two group files may contain, however. As noted above, the CERN/W33 group file can include group entries which consist of other groups. The ncSA group file can include only individual users as members of groups. Thus, the recursive staff group, consisting of all the members of the personnel and management groups, is not possible in ncSA. To create such a group, you would need to re-enter each user’s name in the group entry for staff. Now that you’ve set up your password and group files, you’re ready to add username/password authentication in your GACF or LACFs. Take a look at an example: # Anybody in the personnel group can get to the top level # of the personnel filetree AuthType Basic AuthName Personnel Only AuthUserFile /usr/local/etc/httpd/userpw AuthGroupFile /usr/local/etc/httpd/ourgroup

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services