I made the observation that using the CLI (on PE), which
uses BASIC authentication, each and every HTTP request forces the
client to be reauthenticated on the server. For this to work, each
HTTP request from the CLI carries an "Authorization" header with some
prefabricated credentials, computed from the admin's name and
password, in order to avoid the "WWW-Authenticate" challenge from the
server.
This overhead gets worse by the fact that SSO is turned on by default,
meaning that each time the client has been authenticated, an SSO entry
is created for the authenticated principal. I measured that for the
deployment of a single WAR file (via "asadmin deploy"), a total of
27 (!) SSO entries were created, each carrying the same authenticated
principal. Each SSO entry is stored in a map and keyed by its "ssoid",
a random number that is returned in the response (as the value of the
SSO cookie). This means that for each of the 27 identical SSO entries,
27 random numbers had to be generated - during a single "asadmin deploy"
command, and for no use.
All SSO entries will eventually be purged (their max-inactive-interval
defaults to 5 minutes), but they should not be created in the first
place (or only one should be created and reused).
We could avoid this overhead by having the server component that
processes the request create an HTTP session, which would cause the
web container to store the authenticated principal in that session and
avoid unnecessary reauthentications on subsequent requests. This would
require the CLI to include the session id in subsequent requests.
If we don't want to create any sessions on the server, the CLI could
include the SSO id (received in the response) in subsequent requests,
which will also avoid unneccessary authentications on those requests.
I'm not at all familiar with how the CLI currently processes the HTTP
responses from the server, and if it is capable of processing session or
SSO ids, but it's something we need to investigate (unless this is a
known issue). If this turns out to be impossible, we should at least
consider turning off SSO on the "__asadmin" virtual server.
Please let me know what you think.
Jan