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

v
Resetting
the
session
cache
lifetime
is
configured
to
be
true
(reauth-reset-
lifetime=yes)
At
the
occurrence
of
a
session
lifetime
expiration,
WebSEAL
checks
the
conditions
listed
above.
If
all
conditions
are
met,
the
lifetime
timeout
is
extended
by
the
reauth-extend-lifetime
value
and
the
user’s
session
cache
entry
is
″flagged″
as
extended.
The
session
cache
entry
(containing
the
user
credential)
is
not
removed
and
the
use
can
proceed
to
access
unprotected
resources.
When
the
user
requests
a
protected
resource,
WebSEAL
prompts
the
user
to
reauthenticate.
The
reauth-extend-lifetime
value
should
be
set
to
a
reasonable
value
so
the
user
has
enough
time
to
trigger
the
reauthentication
prompt.
Note
that
if
the
user
does
not
access
a
protected
object
during
the
″grace
period″,
the
reauthentication
process
is
not
activated.
In
this
case,
it
is
possible
for
the
reauth-extend-lifetime
value
to
expire,
in
which
case
the
session
cache
entry
is
removed.
Typically,
however,
reauthentication
policy
is
implemented
to
secure
an
application
that
is
serving
predominantly
protected
resources.
A
time
extension
(″grace
period″)
of
5–10
minutes
should
be
adequate
time
to
allow
an
active
user
to
trigger
the
reauthentication
process,
and
thus
reset
the
session
lifetime
value.
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:
to
include
the
%USERNAME%
macro:
During
an
initial
login,
the
value
for
the
%USERNAME%
macro
is
empty
and
the
user
name
text
field
displayed
on
the
login
page
appears
blank.
For
a
reauthenticating
client,
the
%USERNAME%
macro
now
contains
the
value
of
the
client
user
name.
The
user
name
text
field
on
the
login
page
appears
with
the
user’s
name
automatically
provided.
Chapter
7.
Advanced
WebSEAL
authentication
211