Janus Web Server login caching

While the connectionless nature of the web protocol (HTTP) makes it possible to have servers support communities of tens of thousands of end-users by eliminating the cost of "holding down" open connections, it also presents some special problems.

• Where login security is required, the web protocol results in a login for every page rather than once for a user "session." While Model 204 login processing is fairly inexpensive, this is not necessarily the case for external-authorizer (RACF, ACF2 and Top Secret) login validation. It is possible that external authorizers can be swamped with login requests from Janus Web Server for login protected pages. (In such cases with RACF, a WEBOPT system parameter setting improves performance.
• The ephemeral nature of connections — the browser connects, the server logs in, the user sends the output page and logs off — can make connection-based tools such as SirMon and SirScan difficult to use. For example, simply answering the question "who's using our system now" can be difficult with web users because they never stay logged on for more than a few instants.

Janus Web Server login caching provides a solution to both of these problems. Here is how login caching works: When a user logs on for a web page, rather than logging the user off after the page is sent, the user is left logged on. If another login request is received for the same userid from the same browser (with the same password), that request is transferred to the held login session rather than issuing a new login request.

This accomplishes two things. First, by eliminating the need to re-issue a login request, it eliminates the cost of doing userid and password validation. Second, it makes a web user persist in the Model 204 Online, so it is easier to monitor and audit what individual users are doing.
Note: The userid's password is never kept unencrypted in the Online address space. Instead, before the initial login request, the password is one-way encrypted and stashed in virtual storage. When a subsequent login request is received, the password that comes with that request is one-way encrypted and compared with the saved, one-way encrypted password. If they match, the password must be correct and password validation can be bypassed.

Limiting the number of cached login sessions

Cached login sessions have some real benefits, however, they also have some disadvantages. Like connection-based sessions, each cached login session ties up a thread. Furthermore, these threads are tied up for a fairly long period of time. This means that the number of concurrent web threads might increase significantly if the cached login facility is used.

For example, consider a site that typically has about 200 users concurrently using a Janus Web Server application. Let's say that while they are using the application they are sending an average of one page request every 20 seconds, and let's say that each page request takes one second to satisfy. This translates to an average of about 10 concurrent web threads active at a given time (though realistically the values will range from 0 to 20 or higher). If login caching were turned on, suddenly there would be 200 concurrent web threads at any given instant. While most of these would be inactive most of the time, there would still be costs associated with them.

Most significantly for Model 204, each of these threads would need a server. This means that unless the Online had 200 or more servers there would be server swapping for the web threads. In the non-login caching case, 20 or so servers would probably prevent any web thread server swapping because of Janus Web Server's most-recently-used algorithm for using sdaemon threads.
Note: Because all Janus Web Server applications run on sdaemon threads, the number of sdaemon threads must be increased if login caching is to be used. For more information on setting up sdaemon threads, see the Sirius Mods Installation Guide.

It is clear then, that login caching is no panacea, and in fact, steps should be taken to keep down the number of threads used up by Janus Web Server login caching. Unfortunately, the connectionless nature of the web protocol makes this difficult. There is no such thing as a web logout, and there is no way to determine when the end-user has gone to another web site, exited the browser, or even turned off his or her workstation.

Because of these issues, control of login caching must come through timeouts and system and user limits on cached login sessions. These controls are set with port parameters that are specified on the JANUS DEFINE command.

WEBLOGHOLD	You specify this parameter followed by the length of time (in seconds) that a cached login should be saved for re-use on a web connection. The default for WEBLOGHOLD is 0, which means that login caching is not used for the port. WEBLH is a synonym for WEBLOGHOLD.
WEBLOGMAX	You specify this parameter followed by a number that indicates the maximum number of cached login sessions to be held for a single user. This parameter has no effect unless the WEBLOGHOLD parameter is set to something other than 0. Since a single web page can contain many images, and since browsers often request images on a page in parallel, a single request for such a login-protected page can result in multiple simultaneous logins for a userid. Login caching would then hold these logins, tying up several sdaemons in the process. WEBLOGMAX prevents more than the indicated number of sdaemons to be used for a single user's requests. All login-protected requests for a user are then threaded trough WEBLOGMAX users. This is generally not a problem since the typical bottleneck for most requests is network bandwidth, and multi-threading requests for a single user does not alleviate network bandwidth problems. WEBLM is a synonym for WEBLOGMAX.
WEBSDMAX	This parameter indicates the maximum number of sdaemons to be used for cached web logins. This parameter has no effect unless the WEBLOGHOLD parameter is set to something other than 0. Since there is no upper limit to the number of login requests that can come into a web port at a given instant, it is quite possible for a flurry of login requests to tie up every sdaemon, causing multiple problems including that it makes it impossible for people to connect to any Janus port. WEBSDMAX limits the number of sdaemons that will be used by a port for cached logins. If a new cached login is required, and WEBSDMAX will be exceeded, the oldest cached login session will be discarded, even if WEBLOGHOLD seconds has not been reached for that session. The default for WEBSDMAX is half the number of sdaemons defined to the Online. If sdaemons are used heavily for other purposes in the Online or there are multiple ports using the login caching facility, WEBSDMAX should be adjusted down. WEBSM is a synonym for WEBSDMAX.

The typical strategy in setting these parameters is to set WEBLOGHOLD high enough so that external authorizer logins are avoided, but not so high that too many threads are tied up with cached login sessions. An alternate strategy might be to set WEBLOGHOLD arbitrarily high but to set WEBSDMAX fairly low (perhaps some number less than the number of servers in the Online), limiting the number of cached login sessions for the port. This would have the effect of allowing cached login sessions a longer lifetime when the system is not busy than when it is. This would also have the effect of reducing the likelihood of login-caching related server swapping.

WEBLOGMAX should also be used to limit the overhead associated with simultaneous logins for the same browser, when a browser requests several login-protected images on a page in parallel. Another way to combat this problem is to simply not login protect images, since generally these do not contain secure information anyway.

WEBPUBLOG and login caching

The WEBPUBLOG parameter is used to force a "real" login for the WEBUSER userid for public URL requests. This means that the WEBUSER userid is validated either in CCASTAT or with an external authorizer for public URLs. This type of login is done as a trusted login so no password is required.

There are several reasons for setting the WEBPUBLOG parameter that have nothing to do with login caching, but this parameter also has an interaction with the login caching facility. Specifically, if WEBPUBLOG is set for a port that is also using login caching, login caching will also be used for the WEBUSER logins associated with public URLs. This lets WEBUSER logins get the same benefits: avoiding repeated external authorizer calls, and improved monitoring and auditing of WEBUSER sessions.

One problem associated with using WEBPUBLOG in conjunction with the login caching facility occurs while trying to enforce the WEBLOGMAX parameter. Since WEBLOGMAX limits the number of simultaneous cached login sessions for each user, it becomes essential to be able to distinguish users from each other to determine if requests originate from the same place. This is generally easy with login protected URLs, since (generally) each user will be using a different userid, and the userid uniquely identifies a browser session.

With cached WEBUSER userid logins, however, the userid is no help in distinguishing browser sessions. Because of this, Janus Web Server also uses the browser's IP address in distinguishing browser sessions and so enforcing WEBLOGMAX. Unfortunately, if several browsers are going through the same proxy server, all the browsers' IP addresses appear to be that of the proxy server. In this case, it is impossible to distinguish the individual browser sessions for the enforcement of WEBLOGMAX.

This problem can be solved by the use of the WEBCOOKID parameter on the port definition, which instructs Janus Web Server to send browser requests with cached login sessions a special session cookie that uniquely identifies the browser. Each browser would then send this session cookie back to Janus Web Server on subsequent requests, allowing it to be used to distinguish multiple browser sessions, even if they are going through the same proxy server.

Using WEBCOOKID can be problematic at sites where end-users have browsers that don't support cookies or where end-users have turned off cookie support in their browsers. Fortunately, neither of these is likely in most cases, so WEBCOOKID should be a workable means of distinguishing browsers in most cases.

Login caching and data persistence

It might be tempting to use the login caching facility to achieve data persistence, which is typically not available for web threads. That is, it might be tempting to use global variables, images, foundsets, or lists that can be retrieved on subsequent requests.

While tempting, this is not possible. Even though web login caching avoids doing a real logoff at the end of a request for a page, it does all the normal cleanup that is part of a logoff. This includes cleanup of global variables, images, lists, and foundsets. There are several reasons for this:

• It eliminates the need for web applications to worry about things that are "laying around" in a server as the result of previous requests. These include table sizes, parameter settings, global variables, etc.
• There is no way to ensure that a subsequent request will find the old cached login session still there. As such, even if data were allowed to persist in cached login sessions, applications would still have to cache the data elsewhere in case the old session was not found. This would have rendered this capability somewhat pointless anyway.
• By setting tables back down to the (hopefully) low default sizes, the amount of data that might need to be server-swapped for the cached login session is significantly reduced.

In any case, web technology provides several convenient ways of stashing persistent data on a browser. These include cookies, invisible form fields, and isindex data. In cases where the quantity of data is too great for this to be practical, Model 204 work files can be used. Where it is desirable to save Model 204 lists or found sets, Janus Web Server provides "Saved Record Set Support".