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

Quality
of
protection
POP
policy
The
quality
of
protection
POP
attribute
allows
you
to
specify
what
level
of
data
protection
is
required
when
performing
an
operation
on
an
object.
The
quality
of
protection
POP
attribute
is
used
to
determine
whether
access
will
be
granted
to
requested
resource.
When
an
ACL
check
for
a
resource
succeeds,
the
quality
of
protection
POP
is
checked.
If
a
quality
of
protection
POP
exists,
and
the
resource
manager
(WebSEAL)
cannot
guarantee
the
required
level
of
protection,
the
request
is
denied.
pdadmin>
pop
modify
pop-name
set
qop
{none|integrity|privacy}
When
QOP
level
is
set
to
either
integrity
or
privacy,
WebSEAL
requires
data
encryption
through
the
use
of
Secure
Socket
Layer
(SSL).
For
example:
pdadmin>
pop
modify
test
set
qop
privacy
Handling
unauthenticated
users
(HTTP
/
HTTPS)
WebSEAL
accepts
requests
from
both
authenticated
and
unauthenticated
users
over
HTTP
and
HTTPS.
WebSEAL
then
relies
on
the
authorization
service
to
enforce
security
policy
by
permitting
or
denying
access
to
protected
resources.
The
following
conditions
apply
to
unauthenticated
users
who
access
WebSEAL
over
SSL:
v
The
exchange
of
information
between
the
unauthenticated
user
and
WebSEAL
is
encrypted—just
as
it
is
with
an
authenticated
user.
v
An
SSL
connection
between
an
unauthenticated
user
and
WebSEAL
requires
only
server-side
authentication.
Processing
a
request
from
an
anonymous
client
1.
An
anonymous
client
makes
a
request
to
WebSEAL
(over
HTTP
or
HTTPS).
2.
WebSEAL
creates
an
unauthenticated
credential
for
this
client.
3.
The
request
proceeds,
with
this
credential,
to
the
protected
Web
object.
4.
The
authorization
service
checks
the
permissions
on
the
unauthenticated
entry
of
the
ACL
for
this
object,
and
permits
or
denies
the
requested
operation.
5.
Successful
access
to
this
object
depends
on
the
unauthenticated
ACL
entry
containing
at
least
the
read
(r)
and
traverse
(T)
permissions.
6.
If
the
request
fails
the
authorization
decision,
the
client
receives
a
login
form
(BA
or
Forms-based).
Forcing
user
login
You
can
force
an
unauthenticated
user
to
log
in
by
correctly
setting
the
appropriate
permissions
on
the
unauthenticated
entry
in
the
ACL
policy
that
protects
the
requested
object.
The
read
(r)
and
traverse
(T)
permissions
allow
unauthenticated
access
to
an
object.
To
force
an
unauthenticated
user
to
log
in,
remove
the
read
(r)
permission
from
the
unauthenticated
entry
in
the
ACL
policy
that
protects
the
object.
The
user
receives
a
login
prompt
(BA
or
Forms-based).
126
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide