Java Web Hosting for Developers

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 Tomcat 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 Tomcat Web Hosting services

The Protect directive can specify the protection ruleset be read from a file, rather than from another part of the GACF. In this case, the directive would look like this: Protect /personnel/* /usr/local/etc/httpd/acls/Personnel Here, the absolute pathname to the file named Personnel (not relative to the server DocumentRoot) is specified. This example assumes you’ve created a special subdirectory (/usr/local/etc/httpd/acls) in which to store all your access control information. If you use individual files like this to define your protection rulesets, you need not enter the curly braces that are required in the GACF. This simple example applies username/password authentication access control to all files and subdirectories in the personnel directory, using the following criteria, all of which must be met before access is granted: l Users must enter a username and password. l Usernames and passwords are validated against the file /usr/local/etc/httpd/passwd. l Authenticated usernames are checked for membership in the group named personnel in the groups file /usr/local/etc/httpd/group. Going back to the sample group file, you can see that only users Anne, Joe, and Jerry will be granted access to files in this directory tree. Even if Tom provides his correct password, he will not be given access. This has been a very cursory look at user authentication in the CERN/W3 httpd server. Protect directives and protection rulesets can be quite detailed, including other features not described here. In addition, you can set up both a default protection ruleset and progressively more limited protection rulesets according to your own criteria, adding access control all the way down to the individual file level. For details, see the documentation which comes with the CERN/W3 httpd server software (on the Developing Intranet Applications with Java CD-ROM). Or check out the World Wide Web Consortium’s online CERN/W3 httpd documentation at http://www.w3.org/pub/WWW/Daemon/User/Admin.html. Setting Up Username/Password Authentication in the ncSA httpd Server The ncSA httpd server, along with those derived from it (WinHttpd for Windows and the Apache package for UNIX systems), provide similar username/password authentication mechanisms. Except where there are differences among these packages, I’ll discuss them as a group. Although these packages use authentication methods that are similar to the methods used in the CERN/W3 httpd package, there are differences. Let’s first focus on the similarities. Most importantly, the ncSA packages support both GACFs and LACFs, enabling you to set high-level policy at the server level and then fine-tune it at the directory and subdirectory levels. In addition, both individual user and group authentication are provided for. Finally, some configuration commands, such as AllowOverride, affecting critical items listed earlier might only appear in a GACF. You can also disallow the use of server-side includes and the following of symbolic links, for example, as described earlier. The GACF in the ncSA packages is the file named access.conf (access.cnf in WinHttpd) and is located in the conf subdirectory of your Web server’s file tree. On UNIX systems, the server is usually installed in /usr/local/etc/httpd, and on Windows systems, the server is in c:httpd. In both cases, there exists a conf subdirectory in the top-level httpd directory. However, the layout and syntax of the access.conf file is significantly different from the GACF in the CERN/W3 httpd server. The ncSA file is divided into sections, one for each directory to be controlled. Each directory section in access.conf looks something like this: [ Various configuration commands ]

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

You must specify the name of the password file on the command line, but htadm will prompt you for the function you want to perform and the actual username, password, and user’s real name, as appropriate. (You can use multiple words in the realname field to include a full name and other information.) If you’re in a hurry or have a long list of users to add or delete, you can take advantage of specifying all the htadm command-line arguments at once, like in these examples: # htadm -adduser passwordfile joeuser joespassword Joe User # htadm -deluser passwordfile baduser The first example creates the user joeuser with the password joespassword, and the second deletes the user baduser. This enables you to do mass account deletion using shell looping and to take username, password, and real name input from a file. You’ll need something like the expect package to do automated, mass account creation. There are also -passwd and -check command-line arguments to htadm, which enable you to change and verify passwords, respectively. As with the Netscape server, the CERN/W3 httpd server also enables you to associate individual users with groups. You can set up group authentication rules in LACFs that control access to portions of your Web server document tree. CERN/W3 uses a group file, the format of which is based on the standard UNIX /etc/group format, but it has an added feature for defining access control rules and for recursive inclusion of groups into metagroups. A simple group file, which I’ll use for examples in this chapter, might be something like this: management: tom, mary, joan personnel: anne, joe, jerry staff: management, personnel public: All, Anybody Here, four groups are defined. The first two each contain a list of several individual usernames, but the last two are groups of groups. (Two special groups, All, meaning all authenticated users and Anybody meaning anyone, authenticated or not, are predefined by the CERN/W3 httpd server software, and refer to anyone who might access the server; see the server documentation for details on the distinction between All and Anybody.) After setting up your password and group files, you can add access control protection to your server. As noted, high-level rules go in httpd.conf, the GACF. Access control rules in httpd.conf use the Protect directive and associated protection rulesets. Here’s a simple Protect directive, based on the group file shown above. It implements the example division of your Web server’s document tree into public, management, and personnel subtrees: Protect /personnel/* Personnel This example indicates that all subdirectories and files in the personnel subtrees of your Web server DocumentRoot are subject to the rules in the protection ruleset named Personnel. (You can name protection rulesets with any name you want, but it makes sense to use meaningful names.) According to this Protect directive, the ruleset itself also appears in the GACF, under the label Personnel, and might look like this: Protection Personnel { AuthType Basic Passwordfile /usr/local/etc/httpd/passwd GroupFile /usr/local/etc/httpd/group GetMask personnel } Note

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

Username/Password Authentication The first major element of Web server security is username/password authentication. All the sample Web servers discussed in this book provide this basic kind of security. I kick off this discussion by looking at what the Web browser user sees when he encounters a Web page that requires username/password authentication for access. Figure 5.3 (part of ncSA’s excellent access control tutorial, at http://hoohoo.ncsa.uiuc.edu/docs/tutorials/) shows a Prompt dialog box asking for a username. Once the username is entered, a new dialog box asks for a password, as shown in Figure 5.4. Figure 5.3 : The user is prompted to enter a username on a protected Web page. As you can infer from Figures 5.3 and 5.4, there are three aspects of username/password authentication: the username, the password that applies to that username, and what is permitted to that user when a correct username and password are supplied. Usernames and passwords are meaningless unless you specify a directory, directory tree, or filename to which your username/password access restrictions apply. Figure 5.4 : The user is also prompted for a password on a protected Web page. To make this more understandable, look at an example. Suppose your httpd server’s DocumentRoot directory contains three main subdirectories, named public, management, and personnel. Using your GACF, you can specify that access to the management and personnel subdirectory trees requires username/password authentication, while public is left wide open for anyone to access without being prompted for a username and password. You can also set up LACFs within the protected subdirectories to further limit access to particularly sensitive documents by using usernames/passwords. Setting Up Username/Password Authentication in a Netscape Server Of the servers covered in this book, setting up username/password authentication is simplest in the Netscape servers. The Netscape servers actually use the Netscape browser itself as a graphical interface for administering the server, providing a set of private Web pages and configuration scripts to do so. Using the Server Manager page, you can easily enter new users and their passwords into what Netscape calls the user database. (Your empty user database must first be created before you can add any users and passwords to it.) Figure 5.5 shows the User Database Management screen. Notice there’s an administrative password that must be given, as well as the username and password for the user being added to the database. After you’ve entered this information, click Make These Changes. Figure 5.5 : The Netscape Communications Server Add-User form. After you’ve set up one or more users, you can continue to use the Server Manager to apply access control rules to users. You can associate groups of users together for purposes of authentication, and define access control rules that apply to groups as well as to individuals. With group access controls, users must still provide their own usernames and passwords, but access to a specified area of the server file tree (Netscape calls this a realm) can be controlled by requiring that a user be a member of a group for access. Even if a user provides the correct username and password, he may be denied access based on group access control rules if he is not a member of that realm’s group. Setting Up Username/Password Authentication in the CERN/W3 httpd Server The CERN/W3 httpd server uses a UNIX-like password file (but with only three colon-separated fields) containing usernames, encrypted passwords, and users’ real names. The password file is controlled using the htadm program that comes with the httpd server software. This program enables you to create and delete user accounts, as well as change and verify existing passwords. Although you can provide all the information htadm needs on the command line, it’s easier to let the program prompt you for it. For example, to add a new username and password: # path/to/htadm /path/to/passwordfile

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

can also have their own LACFs. The CERN/W3 server can even extend protection to the individual file level using LACFs. In the Netscape server, lower-level Dynamic Configuration Files serve as LACFs. You can change the names of LACFs in both the ncSA and Netscape servers, but you’re stuck with .www_acl in CERN/W3. With a few important exceptions, you can do everything with an LACF you can do with a GACF. Although you can control access to every directory in your Web server document tree from the GACF, you’ll probably not want to do so, especially if your needs for access control are complex. It’s easy to make mistakes in a lengthy configuration file like the GACF, and you’ll get unexpected, unintended results when you do. These might be hard to track down and might not even show up without extensive testing. Overall, it’s better to use your GACF to establish a high-level security policy and then set up lower-level, simpler controls using LACFs. Note The CERN/W3 server’s LACF files have a completely different format than its GACF. Most of the examples in this chapter apply only to the format of the GACF. What’s the GACF for, then? Most Webmasters use the GACF to establish a general access policy for their Web server. For example, if your Web server is accessible to the Internet at large and you’re not using a firewall system (see the “Firewalls” section later in this chapter) to limit access to your network from the outside, you may want to establish a policy in your GACF that only computers with TCP/IP network addresses that are inside your network can access your Web server’s document tree. Similarly, you can use the GACF to segregate public and private areas on your Web server according to some criteria, and require usernames and passwords for access to the private areas. After you’ve established your overall policies, you can implement LACFs to fine-tune your setup. In doing so, you can selectively apply different access controls to the directory or directories controlled by the LACF. Earlier, exceptions to the statement that you can do everything with an LACF you can do with a GACF were mentioned. Here is a quick, incomplete list; you’ll want to consult detailed server documentation for comprehensive explanations of these and others. The first one applies to all httpd servers, and the last three refer only to UNIX servers. l If you want to control all access on your Web server with your GACF, you can use it to prohibit the use of LACFs altogether. You can deny use of a potentially dangerous and CPU-hogging feature called server-side includes, which actually cause the server to execute outside commands each time a page containing them is accessed, in user Web pages. l You can limit access to CGI-BIN scripts in the server’s main CGI-BIN directory, preventing users from creating potentially dangerous ones in their own Web directories. l l You can prevent potential security problems that can come from following UNIX symbolic links. With respect to symbolic links, confidential files on the system that are completely outside of your Web server tree could be compromised by a naive or malicious user. For example, if a user created a symbolic link in her home directory pointing to the UNIX /etc/passwd file, which contains usernames and encrypted passwords, outside users could obtain a copy of that file using their Web browser and then run a password-cracker on it offline. Of course, a malicious user can grab /etc/passwd himself and run the cracker directly, or e-mail the file to someone else for the same reason, but that’s no reason to make it easy to do so via your intranet. (The UNIX System V /etc/shadow file is not readable by non-root users, nor is the IBM AIX /etc/security/passwd file.) See the section titled “The Common Gateway Interface (CGI) and Intranet Security” later in this chapter for discussion of CGI-BIN and server-side include security issues. These generalities out of the way, let’s turn our attention to the three major elements of Web server security.

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

make sure both information providers and their customers understand a number of critical aspects of intranet security, so they don’t inadvertently defeat the purpose of it. There are network security commonplaces, unrelated to intranet security specifically, that need your attention. All the security precautions in the world can’t protect your intranet from overall poor security practices. Users making poor choices on passwords always leads the list of computer and network security risks. You can limit access to a sensitive Web resource based on the TCP/IP network address of the boss’s pc, but if the boss walks away and leaves his pc unattended without an active screenlock, anyone who walks into the empty office can access the protected resources. Caution Password security is only as good as the passwords that are chosen. Be sure to impose some sort of password setting and changing policy. This will save you time in the end. Unique passwords that are a garble of letters and numbers are the best, but the hardest to remember. Encourage your users to be creative in their password selection. Sometimes a user uses his own name as his password, or his significant other’s or pet’s name; password-guessing is simple for anyone who knows him. Some people write their passwords down and tape them to their keyboards or monitors. These bad habits need to be avoided to completely secure your intranet. In other words, the same good security practices that should be followed in any networked computing environment should also be made to apply in your intranet. Not doing so negates all the possible security steps you can take and reduces the value of your intranet. Even in the absence of malice, the failure to maintain any security on your intranet will inevitably result in an intranet with little real utility and value to its customers. Security on Your Web Server It’s useful to break the overall subject of World Wide Web server security down into three pieces and discuss them separately. I’ll do so in this section, covering user/password authentication, network address access limitations, and transaction encryption. Bear in mind throughout the discussion of these separate pieces that you can combine them in various ways to create flexible and fine-grained access control. In fact, combining two, or even all three, of these methods provides the best overall security. Controlling Access Globally and Locally Before I turn to the individual methods, I’ll cover some high-level information about Web server security setup. Whichever individual security mechanisms you implement on your Web server, the first thing you need to know is that you can implement them at either or both of two levels. First, you can specify high-level access control in a Global Access Configuration File (GACF), specifying overall access rules for your server. In the ncSA httpd server and those which are derived from it, such as the Windows httpd and Apache servers, the GACF is called access.conf. The CERN/W3 server doesn’t have a separate GACF; rather, all access control information is in the main server configuration file, httpd.conf. The Netscape servers have a graphical interface (actually, Netscape Navigator itself) for overall server administration, including setting up access control. If you feel more comfortable editing configuration files, the Netscape server does allow them, calling them Dynamic Configuration Files. Although you can do both global and local configuration using the graphical tool, you can also manually create a top-level Netscape Dynamic Configuration File, which can then be hand-edited to function as a GACF. Second, you can set up per-directory access control using local ACFs (LACFs) for each directory or subdirectory tree. Usually named .htaccess or .www_acl (note the leading periods in the filenames), LACFs lay out access control for an individual directory and its subdirectories, although subdirectories

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

Access to your anonymous FTP server can be limited in several important ways, much like with your HTTP server, while still enabling authorized customers to upload files to it. l l Access to your Usenet news server can be limited in much the same way. l Access to searchable intranet indices and databases can be controlled through password-protected Web interfaces. Access to Gopher services can be controlled based on TCP/IP network address, and separate browse, read, and search permissions can be set on a per-directory basis. l This chapter, doesn’t provide any additional information about these services. You’ll want to refer to the documentation for these network packages to learn about how to handle access control and other security features in them. Securing Users’ Web Browsers Some Web browsers can be set up in kiosk mode, which limits the features of the package that users can access. Available primarily in ncSA Windows Mosaic and Mosaic-based browsers, kiosk mode runs the browser with a limited set of features. Users cannot save, print, or view the HTML source of Web pages, and hotlist/bookmark editing is not allowed. The user cannot even exit from the browser and restart it in normal mode without exiting from Windows altogether. Even the overall Mosaic window cannot be minimized or maximized, and the normal pull-down control menu for Windows is missing. This can be quite effective in a controlled environment. However, end users tend to find their way out of paper bags quite often. Don’t count on kiosk mode being your super security implementation. Figure 5.1 shows ncSA Mosaic for Windows in kiosk mode, and, for your comparison, Figure 5.2 shows the same page in standard Mosaic. As you can see, many of the normal toolbar buttons are missing, as is the Options menu. The remaining pull-down menus are also limited in the available features. Kiosk mode is primarily for use in library or trade-show environments, where users need to be limited in what they can do, but you might find a use for it in your intranet if you need to limit what some customers can do with the package. The Netscape Navigator browser does not have a kiosk mode. Figure 5.1 : ncSA Mosaic for Windows in kiosk mode. Figure 5.2 : ncSA Mosaic for Windows in normal mode. Tip Resourceful users will quickly figure out they can manually edit their pc’s autoexec.bat file or Web browser’s .ini file to override kiosk mode, undoing the limitations you’ve placed on them. If you’re concerned about such things, you’ll need to place user startup and Windows and browser setup files on a file server to which users have read permission only. You’ll also need to limit access to the Mosaic startup command itself, or else users would simply use the Windows Program Manager’s Run command to start another Mosaic session. As a result, kiosk mode might not be worth your trouble except in limited situations, such as at a trade show. It’s Your Call It’s your responsibility to determine the level of security you need on your intranet, and, of course, to implement it. Putting most of the security measures mentioned into place, as you’ll learn in the following sections, is not difficult. Your primary concern will be explaining to customers how intranet security works, not so much as a limiting factor but as an opportunity for increased use and collaboration using your intranet. Assuring decision-makers that they can make information available on your intranet in a secure fashion can go a long way toward making your intranet a success. At the same time, it’s important to

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

On the other hand, implementing some simple, built-in security measures in your intranet can allow you to provide resources you might not have considered possible in such a context. For example, you can give access to some Web pages to some people without making them available to your entire customer base, with several kinds of authentication. In this chapter, you’ll learn how simple security measures can be used to widen the scope of your intranet. To help you get oriented to the material to be presented, the following is a list of chapter objectives. You might want to refer to this list as you work your way through the chapter. In this chapter, you’ll l Consider the overall security aspects of your intranet. l Learn how implementing security on your intranet can actually broaden the ways in which it can be useful in your organization. l Learn how to set up username/password authentication to limit access to resources on your intranet. l Learn how to provide secure access to intranet resources to groups of customers. l Learn how to restrict access to sensitive resources based on customers’ computer hostnames or network addresses. l Learn about the security aspects of CGI-BIN scripting. l Learn about using encrypted data transmission on your intranet to protect critical information. l Learn important information about securing access to your intranet when your corporate network is attached to the Internet. l Learn how to provide-and limit-secure access to your intranet from outside your immediate local network. Intranet security is, then, a multifaceted issue, with both opportunities and dangers, especially if your network is part of the Internet. I’ll walk through the major ones, with detailed information on using built-in intranet security features, in this chapter. Warning Except in the sections of this chapter that are specifically devoted to Internet security issues, it’s assumed that your intranet is not accessible from outside your organization. If you are on the Internet, the intranet security measures discussed in this chapter may not be sufficient to secure your system. If you want to make the services and resources of your intranet accessible from the outside, you’ll need to take significant additional steps to prevent abuse and unauthorized access. Some of these steps are described at the end of this chapter in the section titled “Your Intranet and the Internet.” Why Security? Many people view computer and network security in a negative light, thinking of it only in terms of restricting access to services. One major view of network security is “that which is not expressly permitted is denied.” Although this view is a good way of thinking about how to connect your organization to the Internet, you can, and possibly should, view intranet security from a more positive angle. Properly set up, intranet security can be an enabler, enriching your intranet with services and resources you would not otherwise be able to provide. Such an overall security policy might be described as “that which is not expressly denied is permitted.” This does not mean that you should throw caution to the wind and make everything available to your users on your intranet. There are many things to consider when placing sensitive business data out on your intranet. It may fall into the wrong hands, or worse, be used against your business. This chapter takes the latter approach, presenting intranet security in terms of its opportunities for adding value to your intranet. For example, some of your users might have information they would like to make available, provided access to it can be limited to a specified group-for example, confidential management or financial information. Without the ability to ensure that only those who have the right to see such information will have access, the custodians of such data

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

Chapter 5 Intranet Security CONTENTS l Introduction Why Security? m What Are the Security Features of an Intranet? m It’s Your Call l Security on Your Web Server m Controlling Access Globally and Locally m Username/Password Authentication m Authentication Based on Network Hostname or Address m Combined Authentication l Secure/Encrypted Transactions m Secure HTTP (S-HTTP) m Secure Sockets Layer (SSL) l l The Common Gateway Interface (CGI) and Intranet Security Your Intranet and the Internet m Firewalls m Virtual Intranet l l Summary security si-’kyur- t-e- n: the quality or state of being secure Introduction You might think that there is little reason to be concerned about security in an intranet. After all, by definition an intranet is internal to your organization; outsiders can’t access it. There are strong arguments for the position that an intranet should be completely open to its users, with little or no security. You might not have considered your intranet in any other light.

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