Janus Web Server login caching - Revision history

JAL: link repair

2015-03-09T17:57:25Z

link repair

← Older revision		Revision as of 17:57, 9 March 2015
Line 93:		Line 93:
	if login caching is to be used.		if login caching is to be used.
	For more information on		For more information on
	setting up sdaemon threads, see the [~~http~~:~~//m204wiki.rocketsoftware.com/images/c/c9/~~SiriNew.pdf Sirius Mods Installation Guide].		setting up sdaemon threads, see the <var class="book">[[Media:SiriNew.pdf\|Sirius Mods Installation Guide]]</var>.

	It is clear then, that login caching is no panacea, and in		It is clear then, that login caching is no panacea, and in

JAL: /* Limiting the number of cached login sessions */

2014-12-04T17:25:35Z

Limiting the number of cached login sessions

← Older revision		Revision as of 17:25, 4 December 2014
Line 93:		Line 93:
	if login caching is to be used.		if login caching is to be used.
	For more information on		For more information on
	setting up sdaemon threads, see the [http://~~www~~.~~sirius-software~~.com/~~maint~~/~~download~~/~~siri~~.pdf Sirius Mods Installation Guide].		setting up sdaemon threads, see the [http://m204wiki.rocketsoftware.com/images/c/c9/SiriNew.pdf Sirius Mods Installation Guide].

	It is clear then, that login caching is no panacea, and in		It is clear then, that login caching is no panacea, and in

JAL2 at 20:01, 17 October 2011

2011-10-17T20:01:41Z

← Older revision		Revision as of 20:01, 17 October 2011
Line 121:		Line 121:
	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.</p>		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.</p>
	<p>		<p>
	<var>WEBLOGMAX</var> 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 <var>WEBLOGMAX</var> 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.		<var>WEBLOGMAX</var> 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 <var>WEBLOGMAX</var> 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. </p>
	<p>		<p>
	<var>WEBLM</var> is a synonym for <var>WEBLOGMAX</var>. </p>		<var>WEBLM</var> is a synonym for <var>WEBLOGMAX</var>. </p>
Line 159:		Line 159:
	simply not login protect images, since generally these		simply not login protect images, since generally these
	do not contain secure information anyway.		do not contain secure information anyway.

	==WEBPUBLOG and login caching==		==WEBPUBLOG and login caching==
	The <var>WEBPUBLOG</var> parameter is used to force a "real" login		The <var>[[WEBPUBLOG]]</var> parameter is used to force a "real" login
	for the <var>WEBUSER</var> userid for public URL requests.		for the <var>[[WEBUSER]]</var> userid for public URL requests.
	This means		This means
	that the <var>WEBUSER</var> userid is validated either in CCASTAT or		that the <var>WEBUSER</var> userid is validated either in CCASTAT or
Line 202:		Line 203:
	browser sessions for the enforcement of <var>WEBLOGMAX</var>.		browser sessions for the enforcement of <var>WEBLOGMAX</var>.

	This problem can be solved by the use of the <var>WEBCOOKID</var> parameter		This problem can be solved by the use of the <var>[[WEBCOOKID]]</var> parameter
	on the port definition, which instructs <var class="product">Janus Web Server</var> to send browser		on the port definition, which instructs <var class="product">Janus Web Server</var> to send browser
	requests with cached login sessions a special session cookie		requests with cached login sessions a special session cookie
Line 257:		Line 258:
	work files can be used.		work files can be used.
	Where it is desirable to save <var class="product">Model 204</var>		Where it is desirable to save <var class="product">Model 204</var>
	lists or found sets, <var class="product">Janus Web Server</var> provides [[Janus Web Server Saved Record Set		lists or found sets, <var class="product">Janus Web Server</var> provides [[Janus Web Server Saved Record Set Support\|"Saved Record Set Support"]].
	Support\|"Saved Record Set Support"]].

	[[Category:Janus Web Server]]		[[Category:Janus Web Server]]

JAL2: Created page with "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 "hol..."

2011-10-14T22:45:59Z

Created page with "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 "hol..."

New page

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.
<ul>
<li>Where login security is required, the web protocol
results in a login for every page rather than once for a
user "session."
While <var class="product">Model 204</var> 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 <var class="product">Janus Web Server</var> for
login protected pages.
(In such cases with RACF,
a <var>[[WEBOPT parameter|WEBOPT]]</var> system parameter setting improves performance.
<li>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 <var class="product">[[SirMon]]</var> and <var class="product">[[SirScan]]</var> 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.
</ul>
<var class="product">Janus Web Server</var> 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 <var class="product">Model 204</var> 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.
__TOC__

==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 <var class="product">Janus Web Server</var> 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 <var class="product">Model 204</var>, 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 <var class="product">Janus Web Server</var>'s
most-recently-used algorithm for using sdaemon threads.
 '''Note:'''
Because all <var class="product">Janus Web Server</var> applications run on [[Sdaemons|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 [http://www.sirius-software.com/maint/download/siri.pdf 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 <var class="product">Janus Web Server</var> 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 <var>[[JANUS DEFINE]]</var> command.
<table class="syntaxTable">
<tr><th><var>WEBLOGHOLD</var>
</th><td>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 <var>WEBLOGHOLD</var> is 0, which means that login caching is not used for the port.

<var>WEBLH</var> is a synonym for <var>WEBLOGHOLD</var>. 
</td></tr>
<tr><th><var>WEBLOGMAX</var>
</th><td>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 <var>WEBLOGHOLD</var> 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.

<var>WEBLOGMAX</var> 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 <var>WEBLOGMAX</var> 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.

<var>WEBLM</var> is a synonym for <var>WEBLOGMAX</var>. 
</td></tr>
<tr><th><var>WEBSDMAX</var>
</th><td>This parameter indicates the maximum number of sdaemons to be used for cached web logins. This parameter has no effect unless the <var>WEBLOGHOLD</var> 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. <var>WEBSDMAX</var> limits the number of sdaemons that will be used by a port for cached logins.
If a new cached login is required, and <var>WEBSDMAX</var> will be exceeded, the oldest cached login session will be discarded, even if <var>WEBLOGHOLD</var> seconds has not been reached for that session. 

The default for <var>WEBSDMAX</var> 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, <var>WEBSDMAX</var> should be adjusted down. 

<var>WEBSM</var> is a synonym for <var>WEBSDMAX</var>. 
</td></tr></table>

The typical strategy in setting these parameters is to set
<var>WEBLOGHOLD</var> 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 <var>WEBLOGHOLD</var> arbitrarily high but to set
<var>WEBSDMAX</var> 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.

<var>WEBLOGMAX</var> 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 <var>WEBPUBLOG</var> parameter is used to force a "real" login
for the <var>WEBUSER</var> userid for public URL requests.
This means
that the <var>WEBUSER</var> 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 <var>WEBPUBLOG</var> parameter
that have nothing to do with login caching, but this parameter
also has an interaction with the login caching facility.
Specifically, if <var>WEBPUBLOG</var> is set for a port that is also
using login caching, login caching will also be used for
the <var>WEBUSER</var> logins associated with public URLs.
This lets <var>WEBUSER</var> logins get the same benefits: avoiding
repeated external authorizer calls, and improved monitoring
and auditing of <var>WEBUSER</var> sessions.

One problem associated with using <var>WEBPUBLOG</var> in conjunction
with the login caching facility occurs while trying to
enforce the <var>WEBLOGMAX</var> parameter.
Since <var>WEBLOGMAX</var> 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 <var>WEBUSER</var> userid logins, however, the userid is
no help in distinguishing browser sessions.
Because of
this, <var class="product">Janus Web Server</var> also uses the browser's IP address in distinguishing
browser sessions and so enforcing <var>WEBLOGMAX</var>.
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 <var>WEBLOGMAX</var>.

This problem can be solved by the use of the <var>WEBCOOKID</var> parameter
on the port definition, which instructs <var class="product">Janus Web Server</var> 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 <var class="product">Janus Web Server</var> on subsequent requests,
allowing it to be used to distinguish multiple browser sessions,
even if they are going through the same proxy server.

Using <var>WEBCOOKID</var> 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 <var>WEBCOOKID</var> 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:
<ul>
<li>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.
<li>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.
<li>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.
</ul>

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, <var class="product">Model 204</var>
work files can be used.
Where it is desirable to save <var class="product">Model 204</var>
lists or found sets, <var class="product">Janus Web Server</var> provides [[Janus Web Server Saved Record Set
Support|"Saved Record Set Support"]].

[[Category:Janus Web Server]]