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

4.
After
successful
login,
the
MAS
builds
a
credential
for
the
user,
stores
it
in
the
cache,
and
redirects
the
browser
back
to
the
originally
requested
URL
on
WebSEAL
1
with
an
encrypted
″vouch
for″
token.
In
addition,
a
domain
A-specific
e-community
cookie
is
placed
on
the
browser
to
identify
the
″vouch
for″
server
for
this
domain
(in
this
case,
the
MAS).
If
the
login
attempt
is
unsuccessful,
the
MAS
returns
a
″vouch
for″
token
that
indicates
a
failure
status.
This
token
is
constructed
to
be
indistinguishable
from
a
success
status
″vouch
for″
token.
The
requesting
server
reacts
to
a
failure
status
token
as
if
the
user
had
failed
local
authentication.
5.
WebSEAL
1
decrypts
the
token
and
builds
its
own
credential
for
the
user.
Note:
Identity
mapping
should
not
be
required
within
the
same
domain.
If
identity
mapping
is
required,
WebSEAL
1
must
use
the
Cross-domain
Mapping
Framework
(CDMF).
6.
The
authorization
service
permits
or
denies
the
request.
(2)
FIRST
e-Community
Remote
(Domain
B)
Access:
WebSEAL
3
1.
User
requests
a
resource
protected
by
WebSEAL
3
(remote
domain
B).
The
browser
contains
no
e-community
cookie
for
this
domain.
WebSEAL
3
has
no
cached
credentials
for
the
user.
2.
WebSEAL
3
configuration
has
e-community
authentication
enabled
and
specifies
the
location
of
the
MAS.
WebSEAL
3
redirects
the
browser
to
a
special
″vouch
for″
URL
on
the
MAS.
3.
The
MAS
receives
the
″vouch
for″
request
and,
failing
to
find
credentials
for
that
user,
prompts
the
user
to
login.
4.
After
successful
login,
the
MAS
builds
a
credential
for
the
user,
stores
it
in
the
cache,
and
redirects
the
browser
back
to
the
originally
requested
URL
on
WebSEAL
3
with
an
encrypted
″vouch
for″
token.
In
addition,
a
domain
A-specific
e-community
cookie
is
placed
on
the
browser
to
identify
the
″vouch
for″
server
for
this
domain
(in
this
case,
the
MAS).
If
the
login
attempt
is
unsuccessful,
the
MAS
returns
a
″vouch
for″
token
that
indicates
a
failure
status.
This
token
is
constructed
to
be
indistinguishable
from
a
success
status
″vouch
for″
token.
If
the
user
fails
authentication
at
the
MAS,
then
the
user
is
prompted
for
a
local
authentication
at
WebSEAL
3.
If
the
user’s
account
exists
on
this
server,
authentication
then
succeeds.
5.
WebSEAL
3
decrypts
the
token
and
builds
its
own
credential
for
the
user.
6.
WebSEAL
3
creates
and
sets
a
second
e-community
cookie
(valid
for
domain
B)
on
the
browser,
identifying
WebSEAL
3
as
the
″vouch
for″
server
for
domain
B.
7.
The
authorization
service
permits
or
denies
the
request.
(3)
NEXT
e-Community
Local
(Domain
A)
Access:
WebSEAL
2
1.
User
requests
a
resource
protected
by
WebSEAL
2
(within
the
same
domain
as
MAS).
The
browser
contains
a
domain
A
e-community
cookie
identifying
the
MAS
as
the
″vouch
for″
server.
WebSEAL
2
receives
this
cookie.
WebSEAL
2
has
no
cached
credentials
for
the
user.
2.
WebSEAL
2
configuration
has
e-community
authentication
enabled
and
specifies
the
location
of
the
MAS.
The
presence
of
the
domain
A
e-community
cookie
overrides
the
WebSEAL
2
configuration
for
the
MAS
location.
The
cookie
provides
WebSEAL
2
with
the
identity
of
the
″vouch
for″
server.
(If
scenario
2
occurred
first,
there
would
also
be
a
domain
B
cookie
maintained
on
the
browser
that
would
not
be
sent
to
a
domain
A
server.)
260
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide