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

Understanding
the
“vouch
for”
token
In
order
to
achieve
cross-domain
single
sign-on,
some
user
identity
information
must
be
transmitted
between
servers.
This
sensitive
information
is
handled
using
a
redirect
that
includes
the
identity
information
encrypted
as
part
of
the
URL.
This
encrypted
data
is
called
a
″vouch
for″
token.
v
The
token
contains
the
″vouch
for″
success
or
failure
status,
the
user’s
identity
(if
successful),
the
fully
qualified
name
of
the
server
that
created
the
token,
the
e-community
identity,
and
a
creation
time
value.
v
The
holder
of
a
valid
″vouch
for″
token
can
use
this
token
to
establish
a
session
(and
set
of
credentials)
with
a
server
without
explicitly
authenticating
to
that
server.
v
The
token
is
encrypted
using
a
shared
triple-DES
secret
key
so
that
its
authenticity
can
be
verified.
v
Encrypted
token
information
is
not
stored
on
the
browser.
v
The
token
is
passed
only
once.
The
receiving
server
uses
this
information
to
build
user
credentials
in
its
own
cache.
The
server
uses
these
credentials
for
future
requests
by
that
user
during
the
same
session.
v
The
token
has
a
lifetime
(timeout)
value
that
is
set
in
the
WebSEAL
configuration
file.
This
value
can
be
very
short
(seconds)
to
reduce
the
risk
of
a
re-play
attack.
Configuring
e-community
single
sign-on
e-community
conditions
and
requirements
v
The
e-community
implementation
requires
a
consistent
configuration
across
all
WebSEAL
servers
in
all
domains
participating
in
the
e-community.
v
For
e-community
to
function
successfully,
each
participating
WebSEAL
server
must
reveal
its
fully
qualified
host
name
to
the
other
participating
servers
in
the
cross-domain
environment.
If
any
host
name
does
not
include
a
domain,
e-community
cannot
be
enabled
and
an
error
message
is
logged
in
msg_webseald.log.
When
setting
up
an
e-community
environment,
ensure
that
the
machine-specific
networking
setup
for
each
participating
server
is
configured
to
identify
the
server
with
a
fully
qualified
host
name.
v
All
WebSEAL
servers
participating
in
e-community
must
have
machine
times
synchronized.
Authentication
between
servers
can
fail
when
machine
time
differences
are
too
great.
v
The
e-community
implementation
is
supported
on
both
HTTP
and
HTTPS.
v
The
following
e-community
scenario
is
not
supported
for
production
or
testing
purposes:
a
MAS
WebSEAL
instance
and
a
participating
WebSEAL
server
instance
configured
to
use
the
same
network
interface
on
the
same
machine.
v
Individual
e-community
domains
manage
their
own
user
identities
and
associated
privileges.
You
can
use
the
Cross-domain
Mapping
Function
(CDMF)
API
to
map
a
user
from
a
remote
domain
to
a
valid
user
in
the
local
domain.
If
the
e-community
domains
share
global
user
identities,
those
users
could
be
distinguished
by
different
passwords
in
the
different
domains.
For
example,
a
user
″abc″
can
exist
in
both
domain
A
and
domain
B,
using
different
passwords
for
each
domain.
v
Configuration
for
e-community
is
set
in
the
WebSEAL
configuration
file
of
each
participating
WebSEAL
server.
v
If
the
originally
requested
URL
is
not
redirected
back
to
the
browser
from
the
MAS
(or
″vouch
for″
server),
there
could
be
a
problem
with
page
caching
if
the
Chapter
9.
Client
single
sign-on
solutions
263