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

2.
\Program
Files\Company
Inc.\Release.Notes
3.
\program
files\company
inc\release.notes
Example
1
illustrates
how
Windows
can
create
an
alias
(for
DOS
compatibility)
that
contains
no
spaces
in
the
file
names
and
conforms
to
the
8.3
format.
The
–w
option
causes
WebSEAL
to
reject
this
format
for
ACL
checks.
Example
2
illustrates
how
Windows
can
include
trailing
extension
dots.
The
–w
option
causes
WebSEAL
to
reject
this
format
for
ACL
checks.
Example
3
illustrates
how
Windows
allows
case-insensitivity
on
the
file
name.
The
–w
option
invokes
the
–i
option
to
ensure
a
case-insensitive
ACL
check.
ACLs
and
POPs
must
attach
to
lower-case
object
names
When
a
junction
is
created
with
the
–w
or
–i
option,
WebSEAL
performs
ACL
and
POP
comparisons
as
case-insensitive.
This
means
that
the
name
of
any
object
being
evaluated
for
an
ACL
is
placed
into
lower-case
before
WebSEAL
checks
it
against
the
object
list
to
which
ACLs
are
attached.
As
a
result,
protected
objects
with
names
that
contain
upper
case
letters
are
not
found
during
the
ACL
or
POP
checks.
If
this
occurs,
the
ACL
or
POP
is
not
applied
to
the
protected
object,
and
the
parent
policy
is
applied
instead.
To
avoid
the
possible
misapplication
of
policy
in
this
configuration,
you
must
create
lower-case
versions
of
the
same
names
of
the
real
protected
objects
to
which
you
want
to
attach
explicit
ACLs
or
POPs.
Specifying
UTF-8
encoding
for
HTTP
header
data
WebSEAL
inserts
information
into
HTTP
headers
for
requests
to
the
backend
server.
This
information
can
include
extended
attributes
or
user
data.
In
WebSEAL
versions
prior
to
5.1,
the
headers
were
added
to
the
request
using
raw
local
code
page.
In
Version
5.1,
the
header
data
is
transmitted
in
a
configurable
format.
By
default,
WebSEAL
now
adds
information
to
HTTP
headers
using
UTF-8
encoding.
This
prevents
any
potential
data
loss
that
could
occur
when
converting
to
a
non-UTF-8
code
page.
Also
by
default,
this
data
is
sent
URI
encoded.
For
backwards
compatibility,
the
format
of
the
header
data
can
be
configured
to
raw
local
code
page.
In
addition,
two
other
formats
are
supported:
Raw
UTF-8
and
URI
encoded
local
code
page.
The
-e
option
for
creating
junctions
specifies
the
encoding
of
user
name,
groups,
and
other
extended
attributes
which
are
sent
within
the
HTTP
header
to
the
backend
server.
The
encode
option
can
take
one
of
the
following
arguments:
Argument
Description
utf8_uri
URI
encoded
UTF-8
data
All
white
space
and
non-ascii
bytes
are
encoded
%XY,
where
X
and
Y
are
hex
values
(0–F).
utf8_bin
Un-encoded
UTF-8
data.
This
setting
allows
data
to
be
transmitted
without
data
loss,
and
the
customer
does
not
need
to
URI-decode
the
data.
This
setting
should
be
used
with
caution,
because
it
is
not
part
of
the
HTTP
specification
Chapter
10.
WebSEAL
junctions
305