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

Configuring
reauthentication
based
on
security
policy
Tivoli
Access
Manager
WebSEAL
can
force
a
user
to
perform
an
additional
login
(reauthentication)
to
ensure
that
a
user
accessing
a
protected
resource
is
the
same
person
who
initially
authenticated
at
the
start
of
the
session.
Reauthentication
can
be
activated
by
a
Protected
Object
Policy
(POP)
on
the
protected
object
or
by
expiration
of
the
inactivity
timeout
value
of
a
WebSEAL
session
cache
entry.
This
section
discusses
reauthentication
based
on
security
policy
as
dictated
by
a
POP
extended
attribute.
Background
material
on
the
WebSEAL
session
cache
is
provided
in
“The
WebSEAL
session/credentials
cache
structure”
on
page
10.
Conditions
affecting
POP
reauthentication
Forced
reauthentication
provides
additional
protection
for
sensitive
resources
in
the
secure
domain.
Reauthentication
based
on
security
policy
is
activated
by
a
specific
extended
attribute
in
a
POP
that
protects
the
requested
resource
object.
The
POP
can
be
directly
attached
to
the
object,
or
the
object
can
inherit
the
POP
conditions
from
a
parent
object.
Reauthentication
is
supported
by
the
following
WebSEAL
authentication
methods:
v
Forms
(user
name
and
password)
authentication
v
Token
authentication
In
addition,
a
custom
user
name/password
CDAS
can
be
written
to
support
reauthentication.
Reauthentication
assumes
the
user
has
initially
logged
in
to
the
secure
domain
and
that
a
valid
credential
exists
for
the
user.
During
reauthentication,
the
user
must
log
in
using
the
same
identity
that
generated
the
existing
credential.
WebSEAL
preserves
the
user’s
original
session
information,
including
the
credential,
during
reauthentication.
The
credential
is
not
replaced
during
reauthentication.
During
reauthentication,
WebSEAL
also
caches
the
request
that
prompted
the
reauthentication.
Upon
successful
reauthentication,
the
cached
data
is
used
to
rebuild
the
request.
See
“Server-side
request
caching”
on
page
200.
If
reauthentication
fails,
WebSEAL
returns
the
login
prompt
again.
If
reauthentication
succeeds,
but
the
ACL
check
fails
for
that
resource,
a
403
″Forbidden″
is
returned
and
the
user
is
denied
access
to
the
requested
resource.
In
either
case,
the
user
is
never
logged
off.
Using
a
still
valid
credential,
the
user
can
abort
the
reauthentication
process
(by
requesting
another
URL)
and
still
participate
in
the
secure
domain
by
accessing
other
resources
that
do
not
require
reauthentication.
Configuration
is
available
to
reset
the
lifetime
timer
of
WebSEAL
session
cache
entries.
In
addition,
a
grace
period
can
be
configured
to
allow
sufficient
time
for
the
reauthentication
process
to
complete
before
the
lifetime
timeout
of
a
session
cache
entry
expires.
204
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide