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

Managing
session
state
A
secure
connection,
or
session,
between
a
client
and
a
server
requires
that
the
server
have
the
ability
to
remember—over
numerous
requests—who
it
is
talking
to.
The
server
must
have
some
form
of
session
state
information
that
identifies
the
client
associated
with
each
request.
This
section
contains
the
following
topics:
v
“Session
state
overview”
on
page
132
v
“GSKit
and
WebSEAL
session
cache
overview”
on
page
132
v
“Configuring
the
GSKit
SSL
session
ID
cache”
on
page
133
v
“Configuring
the
WebSEAL
session/credentials
cache”
on
page
133
v
“Maintaining
state
with
session
cookies”
on
page
135
v
“Determining
valid
session
ID
data
types”
on
page
138
Session
state
overview
Without
an
established
session
state
between
client
and
server,
the
communication
between
the
client
and
the
server
must
be
renegotiated
for
each
subsequent
request.
Session
state
information
improves
performance
by
eliminating
repeated
closing
and
re-opening
of
client/server
connections.
The
client
can
log
in
once
and
make
numerous
requests
without
performing
a
separate
login
for
each
request.
WebSEAL
handles
both
HTTP
and
HTTPS
communication.
HTTP
is
a
″stateless″
protocol
and
does
not
provide
any
means
of
distinguishing
one
request
from
another.
The
SSL
transport
protocol,
on
the
other
hand,
is
specifically
designed
to
provide
a
session
ID
to
maintain
session
state
information.
HTTP
communication
can
be
encapsulated
over
SSL
to
become
HTTPS.
However,
WebSEAL
must
often
handle
HTTP
communication
from
unauthenticated
clients.
And
there
are
times
when
the
SSL
session
ID
is
not
an
appropriate
solution.
Therefore,
WebSEAL
is
designed
to
use
any
of
the
following
information
types
to
maintain
session
state
with
a
client:
v
SSL
ID
v
Server-specific
session
cookie
v
BA
header
data
v
HTTP
header
data
v
IP
address
GSKit
and
WebSEAL
session
cache
overview
A
session
cache
allows
a
server
to
store
the
session
ID
information
from
multiple
clients.
WebSEAL
uses
two
types
of
session
caches
to
accommodate
both
HTTPS
and
HTTP
session
state
information.
v
WebSEAL
session/credentials
cache
The
WebSEAL
session/credentials
cache
stores
any
type
of
session
ID
information
(see
the
list
above)
plus
the
credential
information
obtained
for
each
client.
Credential
information
is
cached
to
eliminate
repetitive
queries
to
the
user
registry
database
during
authorization
checks.
v
GSKit
SSL
session
ID
cache
The
GSKit
session
cache
handles
HTTPS
(SSL)
communication
when
SSL
session
ID
information
is
used
to
maintain
session
state.
132
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide