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

Supplying
a
failure
reason
across
a
junction
Authorization
rules
allow
you
to
set
up
special,
and
often
complex,
conditions
governing
the
ability
to
access
a
protected
resource.
However,
the
standard
result
of
a
failed
authorization
decision
is
to
stop
the
progress
of
the
request
to
the
service
application
that
controls
the
resource,
and
present
the
client
with
a
″forbidden″
message.
If
the
authorization
rule
is
written
to
include
a
failure
reason,
and
is
evaluated
as
FALSE
by
the
Tivoli
Access
Manager
authorization
rules
evaluator,
WebSEAL
receives
the
reason
for
the
rule’s
failure
along
with
the
standard
″forbidden″
message
from
the
authorization
service.
The
failure
reason
is
usually
ignored
and
the
″forbidden″
decision
is
enforced
You
can
optionally
configure
WebSEAL
to
reject
this
standard
response
and
allow
denied
requests
to
proceed
across
a
junction
to
a
back-end
service
application.
The
request
is
accompanied
by
the
failure
reason
provided
in
the
authorization
rule.
The
back-end
service
application
can
then
have
the
opportunity
to
proceed
with
its
own
response
to
the
situation.
This
optional
configuration
occurs
during
the
creation
of
the
junction
to
the
back-end
service
application.
Authorization
rules
are
typically
used
in
conjunction
with
service
applications
that
can
understand
and
handle
this
more
sophisticated
level
of
access
control.
In
some
cases,
it
is
necessary
for
the
service
application
to
receive
a
request
that
is
denied
by
the
Tivoli
Access
Manager
authorization
service.
Such
an
application
is
written
to
understand
failure
reason
information
and
can
provide
its
own
response
to
a
request
that
has
failed
a
Tivoli
Access
Manager
authorization
rule.
For
example,
the
order
processing
component
of
a
shopping
cart
application
can
be
governed
by
an
authorization
rule
that
denies
action
on
an
order
if
the
total
purchase
price
exceeds
the
user’s
credit
limit.
It
is
important
for
the
shopping
cart
application
to
receive
the
entire
request
and
the
reason
for
failure.
Now
the
shopping
cart
application
can
take
matters
into
its
own
hands
and
provide
a
user-friendly
response,
such
as
advising
the
user
to
eliminate
a
portion
of
the
order.
The
interaction
with
the
user
is
preserved
rather
than
cut
off.
To
allow
denied
requests
and
failure
reason
information
to
proceed
across
a
junction
to
the
back-end
service
application,
configure
the
junction
with
the
–R
option.
When
WebSEAL
receives
an
access
denied
decision
on
a
request
for
an
object
located
on
a
–R
junction,
WebSEAL
reverses
the
denial
response,
inserts
the
failure
reason
into
an
HTTP
header
called
″AM_AZN_FAILURE″,
inserts
that
header
into
the
request,
and
passes
the
request
on
to
the
back-end
application.
Always
use
this
option
with
caution.
It
is
important
to
coordinate
the
use
of
failure
reasons
in
authorization
rules
with
a
service
application’s
ability
to
interpret
and
respond
to
this
information.
You
do
not
want
to
accidently
create
a
situation
where
access
is
granted
to
a
resource
controlled
by
an
application
that
cannot
respond
accurately
to
the
AM_AZN_FAILURE
header.
Chapter
13.
Authorization
decision
information
retrieval
363