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

If
the
security
policy
does
require
certificate
authentication,
WebSEAL
requests
the
client
certificate.
In
this
mode,
the
SSL
ID
cannot
be
used
to
track
user
session
activity,
because
the
SSL
session
will
be
renegotiated
when
there
is
a
need
to
authenticate
with
certificates.
When
certificate
authentication
takes
place,
WebSEAL
adds
the
SSL
ID
for
the
current
session
into
the
Certificate
SSL
ID
(renegotiation)
cache.
Delayed
certificate
authentication
is
used
in
two
scenarios,
based
on
the
user’s
authentication
status
at
the
time
that
WebSEAL
requests
the
client
certificate.
In
both
scenarios,
a
client
can
have
an
unlimited
number
of
exchanges
with
the
WebSEAL
server
prior
to
establishing
a
need
to
authenticate
using
certificates.
The
two
scenarios
are:
v
User
is
unauthenticated
In
this
scenario,
the
client
remains
unauthenticated
because
the
client
does
not
attempt
to
access
any
resources
that
require
any
authentication.
When
the
client
eventually
attempts
to
access
a
resource
that
requires
authentication
because
of
an
ACL,
WebSEAL
presents
a
certificate
login
page,
and
the
client
can
initiate
certificate
transfer.
WebSEAL
retains
the
entry
in
the
session
cache
for
the
unauthenticated
user,
but
obtains
a
new
SSL
ID
from
GSKit.
When
the
user
successfully
authenticates,
WebSEAL
replaces
the
old
unauthenticated
user
credentials
from
the
session
cache
data
with
the
new
user
credentials.
The
user
is
now
authenticated,
and
able
to
request
access
over
HTTPS
to
resources
that
require
authentication.
v
User
has
previously
authenticated
using
another
authentication
method
In
this
scenario,
the
client
was
required
to
authenticate
to
Tivoli
Access
Manager
during
the
previous
exchanges
with
WebSEAL.
The
previous
authentication
took
place
through
a
different
authentication
method,
such
as
forms
authentication
or
token
authentication.
The
client
eventually
attempts
to
access
a
resource
that
is
protected
by
a
protected
object
policy
(POP)
that
requires
client-side
certificate
authentication
in
order
to
access
the
resource.
WebSEAL
examines
the
current
WebSEAL
authentication
strength
policy
to
determine
the
ranking
of
the
enabled
authentication
methods.
The
authentication
strength
policy
ranks
the
methods
in
a
hierarchy
from
weakest
to
strongest.
When
certificate
authentication
is
ranked
stronger
than
the
client’s
current
authentication
method,
WebSEAL
serves
to
the
client
to
a
login
page
with
a
form
for
certificate
authentication.
When
the
client
successfully
authenticates
using
a
certificate,
the
client’s
authentication
strength
level
is
increased
for
the
duration
of
the
current
session.
WebSEAL
retains
the
user’s
entry
in
the
session
cache,
but
obtains
a
new
SSL
ID
from
GSKit.
WebSEAL
modifies
the
user
data
in
the
user
entry,
by
replacing
the
old
user
credentials
(which
were
based
the
user’s
previous
authentication
method)
with
the
new
user
credentials.
WebSEAL’s
authentication
strength
feature
enables
a
user
to
move
between
different
authentication
levels
during
a
session.
Certificate
authentication
is
one
of
the
authentication
levels
that
can
be
entered
when
a
user
needs
to
increase
(step-up)
authentication
level
in
order
to
access
protected
object
resources.
To
enable
a
user
to
move
up
to
a
certificate
authentication
level,
administrators
must
modify
the
WebSEAL
configuration
file
to
include
certificate
authentication
in
the
list
of
supported
levels
for
authentication
strength.
For
authentication
strength
configuration
instructions,“Authentication
strength
policy”
on
page
117.
150
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide