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

To
solve
this
problem:
1.
Always
write
scripts
that
generate
relative
URL
links.
Avoid
absolute
and
server-relative
URL
links.
2.
If
you
must
use
server-relative
links,
do
not
duplicate
resource
names
and
paths
on
both
the
WebSEAL
server
and
the
junctioned
application
server.
3.
If
you
must
use
server-relative
links,
design
your
ACL
model
so
that
more
prohibitive
ACLs
do
not
affect
false
resources
specified
by
unfiltered
URLs.
Processing
URLs
in
requests
A
difficulty
arises
when
URLs
are
dynamically
generated
by
client-side
applications
(applets)
or
embedded
in
scripts
in
the
HTML
code.
Web
scripting
languages
include
Javascripts,
VBscripts,
ASP,
JSP,
ActiveX,
and
others.
These
applets
and
scripts
execute
as
soon
as
the
page
has
arrived
at
the
client
browser.
WebSEAL
never
has
a
chance
to
apply
its
standard
filtering
rules
to
these
dynamically
generated
URLs.
This
section
describes
how
WebSEAL
processes
client-side
dynamically
generated
server-relative
links
found
in
requests
for
resources
on
junctioned
back-end
servers.
v
“Handling
server-relative
URLs
with
junction
cookies
(-j)”
on
page
292
v
“Handling
server-relative
URLs
with
junction
mapping”
on
page
293
v
“Processing
root
junction
requests”
on
page
294
Note:
There
are
no
solutions
available
for
handling
absolute
URLs
generated
on
the
client-side.
Handling
server-relative
URLs
with
junction
cookies
(-j)
Server-relative
URLs
generated
on
the
client-side
by
applets
and
scripts
initially
lack
knowledge
of
the
junction
point.
WebSEAL
cannot
filter
the
URL
because
it
is
generated
on
the
client-side.
During
a
client
request
for
a
resource
using
this
URL,
WebSEAL
can
attempt
to
reprocess
the
server-relative
URL
using
junction
cookies.
In
the
following
scenario,
a
script
located
on
the
requested
page
dynamically
generates
a
server-relative
URL
expression
upon
arrival
to
the
browser.
If
the
client
requests
the
resource
specified
by
this
link,
WebSEAL
receives
a
request
for
a
local
page.
After
failing
to
find
the
page,
it
returns
a
″Not
Found″
error
to
the
client.
The
–j
option
provides
a
cookie-based
solution
for
handling
server-relative
URLs
that
are
dynamically
generated
by
a
script
that
runs
on
the
client
machine.
General
syntax:
pdadmin>
server
task
server-name
create
...
-j
...
For
each
requested
page,
a
″junction-identifier″
cookie
is
sent
to
the
client
(as
embedded
Java
script
on
the
HTML
page).
The
cookie
contains
the
following
header
name
and
value:
IV_JCT
=
/junction-name
When
the
client
makes
a
request
from
this
page
using
a
dynamically
generated
server-relative
URL,
WebSEAL
(as
before)
receives
a
request
for
a
local
resource.
When
it
fails
to
locate
the
resource,
WebSEAL
immediately
retries
the
request
using
the
junction
information
supplied
by
the
cookie.
With
the
correct
junction
information
in
the
URL
expression,
the
resource
is
successfully
located.
292
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide