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

Although
most
HTTP
servers
support
the
HTTP
specification
that
defines
URLs
as
case-sensitive,
some
HTTP
servers
treat
URLs
as
case-insensitive.
For
example,
on
case-insensitive
servers,
the
following
two
URLS:
http://server/sales/index.htm
http://server/SALES/index.HTM
are
viewed
as
the
same
URL.
This
behavior
requires
an
administrator
to
place
the
same
access
controls
(ACLs)
on
both
URLs.
By
junctioning
a
third-party
server
with
the
–i
option,
WebSEAL
treats
the
URLs
directed
to
that
server
as
case-insensitive.
Attention:
When
using
the
–i
option,
object
names
must
be
lower
case
in
order
for
WebSEAL
to
be
able
to
find
any
ACLs
or
POPs
attached
to
those
objects.
For
more
information,
see
“ACLs
and
POPs
must
attach
to
lower-case
object
names”
on
page
305
Stateful
junction
support
(–s,
–u)
Most
Web-enabled
applications
maintain
a
″state″
for
a
sequence
of
HTTP
requests
from
a
client.
This
state
is
used,
for
example,
to:
v
Track
a
user’s
progress
through
the
fields
in
a
data
entry
form
generated
by
a
CGI
program
v
Maintain
a
user’s
context
when
performing
a
series
of
database
inquiries
v
Maintain
a
list
of
items
in
an
online
shopping
cart
application
where
a
user
randomly
browses
and
selects
items
to
purchase
Servers
that
run
Web-enabled
applications
can
be
replicated
in
order
to
improve
performance
through
load
sharing.
When
the
WebSEAL
server
provides
a
junction
to
these
replicated
back-end
servers,
it
must
ensure
that
all
the
requests
contained
within
a
client
session
are
forwarded
to
the
correct
server,
and
not
distributed
among
the
replicated
back-end
servers
according
to
the
load
balancing
rules.
By
default,
Tivoli
Access
Manager
balances
back-end
server
load
by
distributing
requests
across
all
available
replicated
servers.
Tivoli
Access
Manager
uses
a
″least-busy″
algorithm.
This
algorithm
directs
each
new
request
to
the
server
with
the
fewest
connections
already
in
progress.
The
create
command
–s
flag
overrides
this
load
balancing
rule
and
creates
a
″stateful
junction″
that
ensures
a
client’s
requests
are
forwarded
to
the
same
server
throughout
an
entire
session.
When
the
initial
client
request
occurs,
WebSEAL
places
a
cookie
on
the
client
system
that
contains
the
UUID
of
the
designated
back-end
server.
When
the
client
makes
future
requests
to
the
same
resource,
the
cookie’s
UUID
information
ensures
that
the
requests
are
consistently
routed
to
the
same
back-end
server.
The
–s
option
is
appropriate
for
a
single
front-end
WebSEAL
server
with
multiple
back-end
servers
junctioned
at
the
same
junction
point.
Note
that
as
soon
as
the
initial
junction
is
created
as
stateful,
the
add
command
is
used
without
the
–s
option
to
junction
the
remaining
replicated
back-end
servers
to
the
same
junction
point.
If
the
scenario
involves
multiple
front-end
WebSEAL
servers,
all
junctioned
to
the
same
back-end
servers,
you
must
use
the
–u
option
to
correctly
specify
each
Chapter
10.
WebSEAL
junctions
301