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

The
home
domain
″owns″
the
users—that
is,
it
controls
the
user’s
authentication
information.
Regardless
of
where
a
user
makes
a
request
for
resources,
the
home
domain
is
always
where
the
user
must
authenticate.
Authentication
occurs
against
a
master
authentication
server
(MAS)—a
server
(or
set
of
replica
servers)
that
is
located
in
the
home
domain
and
configured
to
authenticate
all
users.
The
diagram
represents
the
MAS
as
mas.dA.com.
The
duty
of
the
MAS
should
be
restricted
to
providing
authentication
services.
The
MAS
should
not
contain
resources
that
are
available
to
users.
After
a
user
has
successfully
authenticated
to
the
MAS,
the
MAS
generates
a
″vouch
for″
token.
This
token
is
passed
back
to
the
server
where
the
user
is
making
the
request.
The
server
treats
this
″vouch
for″
token
as
proof
that
the
user
has
successfully
authenticated
to
the
MAS
and
can
participate
in
the
e-community.
The
transfer
of
information
between
e-community
domains
is
described
in
detail
in
the
section
“e-community
process
flow”
on
page
258.
e-community
features
and
requirements
v
The
model
supports
access
via
direct
URLs
(bookmarks)
to
resources.
This
feature
contrasts
with
the
CDSSO
model
that
relies
on
a
specially
configured
pkmscdsso
link
(see
“Cross-domain
single
sign-on”
on
page
245).
v
All
users
who
are
participating
in
the
e-community
authenticate
against
a
single
master
authentication
server
(MAS)
located
in
the
home
domain.
v
The
e-community
implementation
allows
for
″local″
authentication
in
remote
domains
if
the
user
does
not
have
a
valid
account
with
the
MAS
(for
example,
users
who
belong
to
domain
B
but
do
not
participate
in
the
domain
A-domain
B
e-community).
Client
Domain A Domain B
mas.dA.com
WebSEAL 1
WebSEAL 2
WebSEAL MAS
WebSEAL 3
WebSEAL 4
ws2.dA.com
ws1.dA.com
ws3.dB.com
ws4.dB.com
Figure
9.
The
e-community
model
Chapter
9.
Client
single
sign-on
solutions
257