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

A
user
who
fails
authentication
with
the
MAS
when
requesting
a
resource
in
a
non-MAS
(but
participating)
domain
is
given
the
option
to
authenticate
to
the
local
server
where
the
request
is
being
made.
v
The
MAS
(and
eventually
other
selected
servers
in
the
remote
domains)
″vouch
for″
the
user’s
authenticated
identity.
v
Domain-specific
cookies
are
used
to
identify
the
server
that
can
provide
″vouch
for″
services.
This
allows
servers
in
a
remote
domain
to
request
″vouch
for″
information
locally.
The
encrypted
contents
of
e-community
cookies
do
not
contain
user
identity
or
security
information.
v
Special
tokens
are
used
to
pass
encrypted
″vouched
for″
user
identity.
The
″vouch
for″
token
does
not
contain
actual
user
authentication
information.
Integrity
is
provided
by
shared
secret
key
(triple-DES).
The
token
contains
a
time-out
(lifetime)
value
to
limit
the
duration
of
the
token
validity.
e-community
process
flow
An
e-community
consists
of
a
master
authentication
WebSEAL
server
(MAS)
and
additional
WebSEAL
servers
located
in
the
home
domain
and
remote
domains.
The
MAS
can
exist
as
a
single
instance
of
a
WebSEAL
server,
or
a
set
of
WebSEAL
replicas
located
behind
a
load
balancer
(where
the
load
balancer
is
identified
as
the
MAS).
All
participating
local
and
remote
WebSEAL
servers
need
to
be
configured
to
use
the
home
domain
MAS
for
initial
client
authentication.
This
is
a
hard
requirement
for
servers
in
the
home
domain,
and
a
soft
requirement
for
servers
in
remote
domains.
For
example,
some
servers
in
remote
domains
can
be
configured
to
handle
their
own
authentication.
These
servers,
and
the
resources
they
protect,
can
operate
independently
of
the
e-community,
even
if
they
are
located
in
a
participating
e-community
domain.
The
e-community
implementation
is
based
on
a
″vouch
for″
system.
Normally,
when
a
user
requests
a
resource
from
a
WebSEAL
server
where
the
user
has
not
established
a
valid
session,
WebSEAL
prompts
the
user
for
authentication
information.
In
an
e-community
configuration,
the
WebSEAL
server
identifies
a
″vouch
for″
server
and
requests
verification
from
this
″vouch
for″
server
that
the
user
has
authenticated.
The
″vouch
for″
server
has
valid
credential
information
for
that
user.
For
the
user’s
first
request,
the
″vouch
for″
server
is
always
the
MAS.
The
MAS
continues
to
serve
as
the
″vouch
for″
server
for
resources
located
in
the
home
domain.
As
the
user
continues
with
resource
requests
across
the
e-community,
an
individual
server
in
each
remote
domain
can
build
its
own
credential
for
the
user
(based
on
user
identity
information
from
the
MAS)
and
assume
the
role
of
″vouch
for″
server
for
resources
in
its
domain.
The
verification
requested
of
the
″vouch
for″
server
takes
the
form
of
a
″vouch
for″
token.
The
″vouch
for″
server
creates
the
token
and
returns
it
to
the
requesting
WebSEAL
server.
The
user
identity
information
in
the
token
is
encrypted.
The
token
contains
a
lifetime
limit.
Upon
receipt
of
the
″vouch
for″
token,
the
requesting
server
builds
credentials
and
a
local
session
for
that
user.
The
user
can
now
access
the
requested
resource
based
on
normal
authorization
controls.
The
user
benefits
from
not
having
to
re-authenticate—a
goal
of
the
e-community
model.
258
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide