This tip is an excerpt of the article "Web authentication: Protecting your Web server" published in the January/February 2005 edition (volume 8, number 1) of the iSeries 400 Experts Journal. Provided courtesy of iSeries 400 Experts.
Authentication using OS/400 user profiles
One technique you can use to authenticate users to the HTTP server is to request and validate an OS/400 user profile and password. Although this approach will intuitively make sense to iSeries programmers and administrators, it offers the least flexibility. In most cases, it will be advisable to use this authentication method only if the Web application user population is limited to people in your enterprise who already have OS/400 user profiles. If you plan to let outsiders use the Web application, it is unlikely that you will want to create OS/400 user profiles for them.
It takes almost no time to configure your Web server to use OS/400 user profile authentication. Figure 2 shows the IBM Web Administration for iSeries page. As shown at the top of the image, the configuration is for a server named WEBSECURE. The server area being affected by the configuration is the root directory of the Web server. Once you navigate to the Web server and server area, you click the Security option in the navigation frame (the left frame on the page). On the Security page, click the Authentication tab and select the OS/400 user profiles option, as shown in the figure. You need to enter a text value for Authentication name or realm. The value you enter is displayed in the browser prompt, as shown in Figure 1.
 |
Figure 1. The ultimate goal is to require a Web user to sign on with a user ID
and password
|
Once you've selected the option and entered the authentication name, you simply restart your Web server. The next time you access the Web server, you will be prompted to enter the user ID and password.
More about the server area
In some cases, what I’ve described above will be all that you need. However, there is “the rest of the story” that you need to be aware of so that you’ll make proper choices for your environment when you use the OS/400 user profiles option.
 |
Figure 2. Select the OS/400 user profiles option on the Authentication tab of the Security page
|
Starting at the top of Figure 2, you need to select the server area that you want to protect. The IBM HTTP server (powered by Apache) applies authentication based on directories in your Web site. The server area Directory / shown in Figure 2 does not mean that the authentication is applied to the root directory of the Integrated File System (IFS). Instead, the Directory / means that this authentication is applied to the document root of the server configuration. When you create a Web server configuration using the IBM HTTP Server Configuration wizard, you specify the document root. You can see the document root directory under the General Settings tab for the Global configuration server area, as shown in Figure 3. For the WEBSECURE Web server, the document root is the IFS directory /www/Websecure/htdocs. So when you select the Directory / in Figure 2 as the server area to protect, you are actually applying the authentication to the document root directory (/www/Websecure/htdocs).
 |
Figure 3. The Document root is set when you create the Web server. View it on the General Server Configuration page
|
The important point to note is that you don’t necessarily have to protect the document root directory. For example, your Web site might contain a combination of static pages and dynamic pages. If the static pages are located in one directory and the dynamic pages in another, you can let all users into your site to access the static pages. You then configure authentication for the directory that contains the dynamic page resources. When Web users click a link in the static page part of your site that links into the dynamic page directory, they are prompted to enter their user ID and password. Many “membership” sites are configured this way, to allow users access to some of the site content but require a user ID and password for access to paid content.
Who’s running the show?
In Figure 2, the next decision you need to make is what user profile will be used after the authentication is completed. For example, you might look at Figure 1 and assume that because user cpelkie entered a user ID and password, the user profile cpelkie is used to process the request.
However, by default, the HTTP server ignores the user profile that is provided on the password entry prompt. In Figure 2, the Process requests using client’s authority option is set to Disabled. Another option, toward the bottom of Figure 2, is to use the OS/400 user profile to process requests.
The general rule is that when you use the default options, all requests to the IBM HTTP server for static pages are handled by user profile QTMHHTTP, and all requests for CGI programs are handled by user profile QTMHHTP1. That means that you need to pay attention to your IFS directory and file permissions so that those user profiles (or *PUBLIC) have read and execute access to the directories and files. (As an aside, I was always puzzled by the requirement for execute access to a directory until I learned that execute access is required for a user profile to search within and traverse a directory. If you have directories that are several levels deep, the user profile will need to execute access to the higher-level directories so that it can get to the lower-level directories.)
As shown in Figure 2, you have two additional options for designating the user profile that is used after authentication. If you change the Process requests using client’s authority to Enabled, the user profile that you enter in Figure 1 is used, much as with a green-screen sign-on. However, if you supply an OS/400 user profile to process requests (toward the bottom of Figure 2), you are essentially overriding the user profile that was entered with the specific user profile that you supply.
Rather than attempt to describe how these options are related, I refer you to Table 1. The table shows what happens when you select various combinations of OS/400 user profile and process request options.
 |
Table 1. How the "process requests" options are related
|
Accessing the user profile in your programs
Before leaving the OS/400 user profile option, you should know that you could programmatically access the OS/400 user profile that is used to process your request. For example, in some programs, you might want to know the user profile name to perform additional processing based on that profile.
The HTTP server makes the user profile that was used for sign-on (in Figure 1) available to your program in an environment variable named REMOTE_USER. How you access an environment variable is language dependent; for example, RPG CGI uses a different technique than Net.Data.
If you enter the OS/400 user profile to process request option (bottom of Figure 2), you can also select the option to provide a profile token to CGI programs. When you use that option, you use the environment variable HTTP_AS_AUTH_PROFILETKN to access the profile token that was generated by the Web server to represent the user profile. In some cases, you might have to enter a user profile to sign on but provide a user profile to process requests (Result 5 in Table 1). If so, you can access both of the environment variables to determine the user profile used to sign on and the user profile that is used to process the request.
---------------------------
About the author: Craig Pelkie develops training materials for iSeries programmers. You can find information about his materials and additional articles at www.Lab400.com. He can be contacted at pelkie@Lab400.com.
This tip is an excerpt of the article "Web authentication: Protecting your Web server" published in the January/February 2005 edition (volume 8, number 1) of the iSeries 400 Experts Journal. Provided courtesy of iSeries 400 Experts.
