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

Extending
the
session
cache
entry
lifetime
value
It
is
possible
for
the
lifetime
value
of
a
session
cache
entry
to
expire
while
the
user
is
performing
a
reauthentication.
This
situation
occurs
under
the
following
conditions:
v
The
user
requests
a
resource
protected
by
a
reauthentication
POP
v
The
user’s
session
cache
entry
lifetime
value
is
very
near
expiration
The
lifetime
of
a
session
cache
entry
can
expire
after
the
reauthentication
login
form
is
sent
to
the
user
and
before
the
completed
login
form
is
returned.
When
the
session
cache
entry
lifetime
value
expires,
the
session
cache
entry
is
deleted.
When
the
login
form
is
returned
to
WebSEAL,
there
is
no
longer
a
session
for
that
user.
In
addition,
all
cached
user
request
data
is
lost.
You
can
configure
a
time
extension,
or
″grace
period,″
for
the
session
cache
entry
lifetime
value
if
the
session
cache
entry
lifetime
expires
during
reauthentication.
The
reauth-extend-lifetime
parameter
in
the
[reauthentication]
stanza
of
the
webseald.conf
configuration
file
provides
this
time
extension,
in
seconds.
For
example
(5
minutes):
[reauthentication]
reauth-extend-lifetime
=
300
The
default
value,
″0″,
provides
no
extension
to
the
session
cache
entry
timeout
value.
The
reauth-extend-lifetime
parameter
applies
to
users
with
existing
session
cache
entries
and
who
are
required
to
reauthenticate.
For
example:
v
Users
performing
reauthentication
resulting
from
POP
security
policy
v
Users
performing
reauthentication
resulting
from
session
cache
inactivity
v
Users
performing
step-up
authentication
The
reauth-extend-lifetime
option
is
intended
to
be
used
in
conjunction
with
the
reauth-reset-lifetime=yes
option.
This
parameter
is
also
appropriate
for
reauthentication
due
to
the
expiration
of
the
session
cache
entry
inactivity
timeout
value.
See
“Configuring
reauthentication
based
on
session
inactivity
policy”
on
page
208.
Customizing
login
forms
for
reauthentication
WebSEAL
supports
reauthentication
for
both
forms
and
token
authentication
methods.
By
default,
forms
authentication
uses
the
login.html
page
to
request
user
name
and
password
information
from
the
client
(see
“Custom
HTML
page
descriptions”
on
page
89).
By
default,
token
authentication
uses
the
tokenlogin.html
page
to
request
user
name
and
token
passcode
information
from
the
client
(see
“Custom
HTML
page
descriptions”
on
page
89).
These
same
default
login
pages
are
also
used
during
reauthentication.
During
initial
login,
both
user
name
and
password
(passcode)
fields
are
blank
in
each
of
these
login
pages.
However,
it
is
possible
to
have
the
user
name
field
in
these
login
pages
automatically
filled
in
during
reauthentication
by
using
the
%USERNAME%
macro
(see
“Macro
support
for
account
management
pages”
on
page
89).
The
client
needs
to
complete
only
the
password
(passcode)
field.
For
example,
modify
the
following
line
in
the
login.html
page:
206
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide