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

Workaround:
As
administrator,
you
can
force
an
immediate
halt
to
user
activity
in
a
domain
by
adding
an
entry
to
the
default
WebSEAL
ACL
policy
for
the
deleted
user
with
the
traverse
(T)
permission
removed.
You
can
also
terminate
the
session
manually,
using
either
from
a
command
line
or
using
a
Tivoli
Access
Manager
administration
API
function.
See
“Terminating
user
sessions”
on
page
345.
Maintaining
state
with
session
cookies
One
method
of
maintaining
session
state
between
a
client
and
a
server
is
to
use
a
cookie
to
hold
this
session
information.
The
server
packages
the
state
information
for
a
particular
client
in
a
cookie
and
sends
it
to
the
client’s
browser.
For
each
new
request,
the
browser
re-identifies
itself
by
sending
the
cookie
(with
the
session
information)
back
to
the
server.
Session
cookies
offer
a
possible
solution
for
situations
when
the
client
uses
a
browser
that
renegotiates
its
SSL
session
after
very
short
periods
of
time.
For
example,
some
versions
of
the
Microsoft
Internet
Explorer
browser
renegotiate
SSL
sessions
every
two
or
three
minutes.
A
session
cookie
provides
reauthentication
of
a
client
only
to
the
single,
unique
server
that
the
client
had
previously
authenticated
to
within
a
short
time
period
(around
ten
minutes).
The
mechanism
is
based
on
a
″server
cookie″
that
cannot
be
passed
to
any
machine
other
than
the
one
that
generated
the
cookie.
In
addition,
the
session
cookie
contains
only
a
random
number
identifier
that
is
used
to
index
the
server’s
session
cache.
There
is
no
other
information
exposed
in
the
session
cookie.
The
session
cookie
cannot
compromise
security
policy.
Session
cookie
conditions
WebSEAL
uses
a
secure
server-specific
session
cookie.
The
following
conditions
apply
to
this
cookie
mechanism:
v
Cookie
contains
session
information
only;
it
does
not
contain
identity
information
v
Cookie
resides
only
in
the
browser
memory
(it
is
not
written
to
the
browser
cookie
jar
on
the
disk)
v
Cookie
has
a
limited
lifetime
v
Cookie
has
path
and
domain
parameters
that
prohibit
its
use
by
other
servers
Session
cookies
with
basic
authentication
headers
When
a
client
requests
access
to
a
protected
resource,
and
WebSEAL
is
configured
to
use
BA,
WebSEAL
sends
a
session
cookie
to
the
client.
Clients
such
as
browsers
can
be
configured
to
either
accept
or
reject
cookies.
After
the
client
accepts
or
rejects
the
cookie,
WebSEAL
authenticates
the
user
by
prompting
for
username
and
password.
When
a
client
accepts
the
session
cookie
and
then
successfully
logs
in,
WebSEAL
matches,
for
each
additional
request
by
the
client,
the
session
ID
from
the
cookie
with
an
existing
entry
in
WebSEAL’s
session
cache.
Thus
WebSEAL
does
not
need
to
reauthenticate
the
client.
This
use
of
the
same
session
ID
optimizes
server
performance.
When
the
client
rejects
the
session
cookie
and
then
successfully
logs
in,
WebSEAL
must,
for
each
additional
request
by
the
client,
establish
a
new
session
by
Chapter
6.
Authentication
135