Protecting Your AS/400 Information

Unavailable through the Web Server

This is information that you don't want anyone to view through the Web Server. It may be personal or valuable information that is on the same AS/400 as the Web Server, but you don't want users to be able to access it through the Web Server.

The two methods you have for protecting this information are OS/400 authority and Web Server/400 scope control. OS/400 authority is very strong, but may be hard to configure and maintain. Web Server/400 scope control should be easier to maintain and is already set up when you install the server.

Note that a third method, access control can also be used for this information. Access control will be further described later.

Available to all users who have access to the Web Server

This is information that you want generally available. It may include press releases and other announcements or marketing material. If your Web Server is only available through an internal network, you might include other information here, such as company-wide announcements.

The same two methods as above are used to make information available (OS/400 authority and Web Server/400 scope control). The difference is that you would use the methods to make this information available, rather than unavailable.

Available to a subset of users who have access to the Web Server

This is information that should be available to some users who have access to the Web Server, but not all. It might include information only available to customers, or information only available internally, even though the Web Server itself if available to the public (e.g. through the Internet).

The method for protecting this information is access control. Using access control, you can specify (on a per-directory basis if you like) who can access information, either based on the on the machine they are using or based on a user name and password they enter, or a combination of the two.

Note that this document only describes protecting your AS/400 information in regards to Web Server/400. Other software such as Telnet and FTP pose additional concerns which are not addressed here.

OS/400 Authority

For OS/400 authority to be effective, your system's security level (system value QSECURITY) should be set to at least 30. Web Server/400 has been developed and tested at security level 40.

The server jobs (daemon and request processors) that serve content run under the configured server user profile. The server user profile should have the following authorities:

• *USE to any documents you want to make available to browsers.
• *USE to any scripts the server should be able to execute.
• *USE to the WWWSERVER/WWWDAEMON program and to the QSYS/QSYSNOMAX job queue.
• The server user profile must be registered in the system directory in order to access Document Library Services (DLS) folders and documents.

To protect information from being accessed through Web Server/400 using OS/400 authority, you must ensure that the server user profile does not have access to it. You can do this by either specifically excluding the server user profile, or by excluding *PUBLIC.

Web Server/400 Scope Control

• Server root path
• Include library
• Enable Scripts
• Script library
• Public user directory

Web Server/400 Access Control

Modes For Evaluating Access

By default, all hosts and users have normal access to all documents (that OS/400 authority allows), and no hosts and users have administrative access to any documents.

Ways Of Controlling Access

Host filtering

Allows restriction of access to information based on the IP address or domain name of the machine (host) requesting the information.

User authentication

Allows restriction of access to information based on a user ID and password the user enters.

Evaluating Web Server/400 access involves a two step process:

1. Host filtering will be checked first. If host filtering is not configured or allows access, the server goes on to the next step. If host filtering does not allow access, the server will forbid access.
2. User authentication is checked. If user authentication is not configured or allows access, then access is granted. If user authentication does not allow access, the server will forbid access.

Note that Web Server/400 access control is based entirely on files and their relationship within IFS. Because Web Server/400 does not take into account symbolic links, you must protect any symbolic links leading to a file in the same way you protect the file itself.

Remember, even if Web Server/400 access control allows access, OS/400 authority must allow the server user profile access to information before it can be sent back to a browser.

Further Information About Protecting Your AS/400

• Server user profile
• Access log (for auditing accesses and attempted accesses)
• Domain name lookup (affects host filtering)
• Authentication User Storage
• Access control configuration files
  • Directory based configuration file path
  • Directory based configuration file
  • Administrative access control file path
  • Administrative access configuration file
  • User access file
  • Group access file
• Configuration values used in access control configuration files
  • Directory section start
  • Authentication group file
  • Authentication realm name
  • Authentication type
  • Authentication user file
  • Limit section start
  • Limit section end
  • Directory section end
  • Order
  • Allow hosts
  • Deny hosts
  • require user authentication