IBM Tivoli Access Manager for e-business: WebSEAL Administration ...

Server-side
request
caching
This
section
contains
the
following
topics:
v
“Overview
of
server-side
request
caching”
v
“Configuring
server-side
caching
parameters”
on
page
201
Overview
of
server-side
request
caching
In
past
versions
of
WebSEAL
using
Forms
authentication,
WebSEAL
created
a
cache
entry
for
the
URL
of
a
user
request
whenever
authentication
was
required.
Upon
successful
authentication,
WebSEAL
sent
an
HTTP
redirect
to
the
browser
that
included
this
URL.
The
browser
then
followed
the
redirect
to
the
original
resource
location.
The
limitation
of
this
implementation
became
apparent
when,
for
example,
a
POST
request
was
interrupted
by
a
session
timeout
that
prompted
a
re-authentication
process.
Since
WebSEAL
only
cached
the
URL
of
the
original
request,
the
POST
data
(including
the
METHOD
and
Message
Body)
were
lost
during
the
HTTP
redirect.
The
user
had
to
rebuild
the
POST
request.
WebSEAL
now
caches
a
more
complete
set
of
request
data
and
uses
this
cached
data
to
rebuild
the
request
during
the
HTTP
redirect,
if
a
re-authentication
requirement
interrupts
the
completion
of
the
request
processing.
This
solution
particularly
benefits
POST
and
PUT
requests,
because
these
requests
types
can
include
a
variety
of
information
fields.
When
an
authentication
requirement
interrupts
a
request,
WebSEAL
caches
all
information
necessary
to
rebuild
the
request
during
the
HTTP
redirect
that
follows
after
re-authentication.
Cached
request
data
includes
URL,
METHOD,
Message
Body,
query
strings,
and
all
HTTP
headers
(including
cookies).
This
data
is
temporarily
stored
in
the
WebSEAL
credentials/session
cache.
Upon
successful
authentication
(or
re-authentication),
WebSEAL
sends
an
HTTP
redirect
to
the
browser.
The
browser
follows
the
redirect
to
the
original
URL
contained
in
the
redirect.
WebSEAL
intercepts
the
redirect
and
rebuilds
the
request
using
the
cached
data.
The
rebuilt
request
is
delivered
to
the
URL
destination.
The
following
diagram
illustrates
a
typical
server-side
request
caching
process
flow:
1.
User
successfully
logs
in
(Forms
authentication)
and
submits
an
HTTP
request
for
a
resource
involving
a
CGI-generated
data
form.
WebSEAL
creates
and
caches
a
session
ID
for
the
user.
2.
The
back-end
application
server
returns
the
form
to
the
user.
3.
During
the
time
it
takes
the
user
to
fill
in
the
form,
the
configured
session
timeout
for
the
user
expires.
WebSEAL
removes
the
user’s
credentials
cache
entry
and
session
ID.
4.
The
user
eventually
submits
the
completed
form
(POST).
WebSEAL
finds
no
cache
entry
for
the
user,
creates
a
new
cache
entry,
and
temporarily
caches
the
complete
information
contained
in
the
POST
request.
5.
Because
WebSEAL
finds
no
credentials
for
this
user,
the
user
must
authenticate.
WebSEAL
sends
a
login
form
to
the
user.
6.
The
user
returns
the
completed
login
form
to
WebSEAL
(POST).
Authentication
is
successful.
The
cache
now
contains
the
user’s
credentials,
as
well
as
the
cached
request.
200
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide