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

7.
WebSEAL
sends
an
HTTP
redirect
back
to
the
browser
containing
the
URL
of
the
originally
requested
resource.
8.
The
browser
follows
the
redirect
(GET).
WebSEAL
intercepts
the
redirect
and
rebuilds
the
original
request
(form)
using
the
cached
POST
data.
The
restored
request
(form)
is
delivered
to
the
URL
designation.
Usage
notes
v
The
server-side
caching
parameters
protect
WebSEAL
from
denial
of
service
attack
types
that
could
cause
WebSEAL
to
cache
more
data
than
it
can
handle.
v
Server-side
request
caching
will
not
function
correctly
if
the
user
session
time
out
value
expires
during
the
login
process.
In
this
situation,
the
cache
entry
is
lost.
v
Server-side
request
caching
can
cause
limitations
with
the
browser’s
ability
to
manipulate
the
resource.
The
browser
is
unaware
that
WebSEAL
has
rebuilt
the
HTTP
redirect.
Therefore
the
browser’s
reload/refresh
function
and
caching
ability
can
be
hindered.
Configuring
server-side
caching
parameters
WebSEAL
automatically
caches
requests
during
Forms
authentication.
You
can
modify
settings
in
the
[server]
stanza
of
the
WebSEAL
configuration
file
to
specify
limits
to
the
size
of
the
requests
that
WebSEAL
caches.
The
following
sections
describe
the
settings
that
you
can
modify:
v
“Modifying
max-client-read”
on
page
202
v
“Modifying
request-max-cache”
on
page
203
Client WebSEAL
Web
Application
Server
junction
login and request request
application form
session time out
submit form cache
request data
Forms login page
authenticate
HTTP redirect
browser follows
redirect (GET)
original request
data received
WebSEAL intercepts
and supplies
cached data
1
2
4
5
6
7
8
3
Figure
6.
Example
WebSEAL
request
caching
process
flow
Chapter
7.
Advanced
WebSEAL
authentication
201