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

3.
WebSEAL
2
redirects
the
browser
to
a
special
″vouch
for″
URL
on
the
domain
A
″vouch
for″
server
identified
in
the
cookie
(in
this
case
the
MAS,
because
WebSEAL
2
is
in
domain
A).
4.
The
MAS
receives
the
″vouch
for″
request
and
finds
credentials
for
that
user
in
the
cache
(this
occurred
in
scenario
1
and
2).
5.
The
MAS
redirects
the
browser
back
to
the
originally
requested
URL
on
WebSEAL
2
with
an
encrypted
″vouch
for″
token.
6.
WebSEAL
2
decrypts
the
token
and
builds
its
own
credential
for
the
user.
7.
The
authorization
service
permits
or
denies
the
request.
(4)
NEXT
e-Community
Remote
(Domain
B)
Access:
WebSEAL
4
1.
User
requests
a
resource
protected
by
WebSEAL
4
(remote
domain
B).
If
scenario
2
occurred
first,
the
browser
contains
a
domain
B
e-community
cookie
identifying
WebSEAL
3
as
the
″vouch
for″
server.
WebSEAL
4
has
no
cached
credentials
for
the
user.
2.
WebSEAL
4
configuration
has
e-community
authentication
enabled
and
specifies
the
location
of
the
MAS.
The
presence
of
a
domain
B
e-community
cookie
overrides
the
WebSEAL
4
configuration
for
the
MAS
location.
The
cookie
provides
WebSEAL
4
with
the
identity
of
the
″vouch
for″
server.
(If
scenario
1
occurred
first,
there
would
only
be
a
domain
A
cookie
maintained
on
the
browser
that
would
not
be
sent
to
a
domain
B
server.
The
configured
MAS
location
would
be
used
instead.
WebSEAL
4
would
then
become
the
″vouch
for″
server
for
domain
B.)
3.
If
scenario
2
occurred
first,
WebSEAL
4
redirects
the
browser
to
a
special
″vouch
for″
URL
on
the
domain
B
″vouch
for″
server
identified
in
the
domain
B
cookie
(in
this
case
WebSEAL
3).
4.
WebSEAL
3
receives
the
″vouch
for″
request
and
finds
credentials
for
that
user
in
the
cache
(this
occurred
in
scenario
2).
5.
WebSEAL
3
redirects
the
browser
back
to
the
originally
requested
URL
on
WebSEAL
4
with
an
encrypted
″vouch
for″
token.
6.
WebSEAL
4
decrypts
the
token
and
builds
its
own
credential
for
the
user.
7.
The
authorization
service
permits
or
denies
the
request.
(5)
ANOTHER
e-Community
Local
(Domain
A)
Access:
WebSEAL
2
1.
User
connects
to
WebSEAL
2
(domain
A)
with
a
request.
If
scenario
3
occurred,
WebSEAL
2
has
cached
credentials
for
the
user.
2.
The
authorization
service
permits
or
denies
the
request.
Logout
from
the
e-Community
v
If
the
user
logs
out
by
closing
the
browser,
all
SSL
sessions
and
all
e-community
cookies
are
cleared.
v
If
the
user
logs
out
via
the
/pkmslogout
page,
the
SSL
session
and
e-community
cookie
for
that
domain
are
cleared.
Understanding
the
e-community
cookie
v
The
e-community
cookie
is
a
domain-specific
cookie
set
by
one
WebSEAL
server,
stored
in
the
memory
of
the
user’s
browser,
and
transmitted
to
other
WebSEAL
servers
(in
the
same
domain)
in
subsequent
requests.
Chapter
9.
Client
single
sign-on
solutions
261