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

Replicated
front-end
WebSEAL
servers
Note:
The
following
information
replaces
the
former
pdadmin
server
modify
baseurl
command,
used
in
previous
versions
of
Tivoli
Access
Manager.
In
a
heavy
load
environment,
it
is
advantageous
to
replicate
front-end
WebSEAL
servers
to
provide
better
load-balancing
and
fail-over
capability.
When
you
replicate
front-end
WebSEAL
servers,
each
server
must
contain
an
exact
copy
of
the
Web
space,
the
junction
database,
and
the
dynurl
database.
This
version
of
Tivoli
Access
Manager
supports
a
manual
configuration
procedure
to
replicate
front-end
WebSEAL
servers.
The
pdadmin
command
is
no
longer
used
for
this
task.
In
the
following
example,
″WS1″
is
the
host
name
of
the
primary
WebSEAL
server.
″WS2″
is
the
host
name
for
the
replica
WebSEAL
server.
1.
Install
and
configure
WebSEAL
on
both
WS1
and
WS2
servers.
2.
Using
the
pdadmin
command,
create
a
new
object
to
be
the
root
of
the
authorization
space
for
both
WebSEAL
servers.
For
example:
pdadmin>
object
create
/WebSEAL/newroot
3.
Stop
WebSEAL
on
WS1.
4.
On
WS1,
change
the
value
of
the
server-name
parameter
in
the
WebSEAL
configuration
file
from
″WS1″
to
″newroot″:
[server]
server-name
=
newroot
5.
Restart
WebSEAL
on
WS1.
6.
Repeat
Steps
3-5
for
WS2.
The
WS1
and
WS2
servers
now
use
the
object
/WebSEAL/newroot
as
the
base
for
authorization
evaluations.
Either
the
WS1
or
the
WS2
server
can
respond
to
object
list
and
object
show
commands
for
objects
residing
below
/WebSEAL/newroot.
Use
the
following
procedure
when
unconfiguring
either
WS1
or
WS2:
1.
Stop
the
WebSEAL
server.
2.
Change
the
server-name
parameter
back
to
its
original
value.
For
example,
for
WS1:
[server]
server-name
=
WS1
3.
Proceed
with
normal
unconfiguration
procedures.
Conditions:
v
Unified
object
space
management:
Although
a
single
object
hierarchy
is
visible
to
the
administrator,
all
replicated
WebSEAL
servers
are
affected
by
administration
commands
applied
to
that
object
hierarchy
and
all
servers
are
able
to
respond
to
these
commands.
v
Unified
authorization
evaluation:
Both
WS1
and
WS2
use
/WebSEAL/newroot
as
the
base
for
authorization
evaluations.
v
Unified
configuration:
For
front-end
WebSEAL
replication
to
function
correctly,
the
Web
space,
junction
database,
and
dynurl
database
configuration
must
be
identical
on
each
server.
58
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide