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

pdadmin>
pop
modify
test
set
ipauth
add
9.1.2.3
255.255.255.0
0
v
Deny
access
based
solely
on
IP
address,
or
range
of
IP
addresses,
regardless
of
authentication
strength
level.
This
restriction
is
enforced
by
using
the
key
word
forbidden
as
the
final
parameter.
For
example,
to
restrict
only
the
client
at
IP
address
9.1.2.3
from
accessing
the
protected
resource:
pdadmin>
pop
modify
test
set
ipauth
9.1.2.3
255.255.255.255
forbidden
Likewise,
to
restrict
requests
from
all
IP
addresses
on
the
9.1.2.x
subnet
from
accessing
the
resource:
pdadmin>
pop
modify
test
set
ipauth
9.1.2.3
255.255.255.0
forbidden
v
Prevent
requests
from
all
IP
addresses
from
accessing
the
protected
object,
unless
the
IP
address
has
been
enabled
by
a
previous
pop
modify
set
ipauth
add
command.
For
example,
in
a
use
case
above,
a
range
of
IP
addresses
were
required
to
access
the
protected
resource
by
using
authentication
strength
level
1:
pdadmin>
pop
modify
test
set
ipauth
add
9.1.2.3
255.255.255.0
1
The
administrator
can,
in
addition,
specify
that
requests
from
all
other
IP
addresses
will
be
denied,
regardless
of
authentication
strength
level,
in
the
following
pdadmin
command:
pdadmin>
pop
modify
test
set
ipauth
anyothernw
forbidden
The
option
anyothernw
means
any
other
network
address,
and
the
option
forbidden
enforces
the
denial
policy.
Attach
a
protected
object
policy
to
a
protected
resource
After
a
protected
object
policy
(POP)
has
been
defined
and
created,
it
must
be
attached
to
the
protected
resources
to
which
it
applies.
The
syntax
for
attaching
a
POP
is:
pdadmin
pop
attach
object_name
pop_name
For
example,
an
authentication
policy
for
a
WebSEAL
deployment
could
be
defined
as
follows:
v
The
deployment
will
use
forms
authentication
and
certificate
authentication.
Forms
authentication
is
the
first
authentication
strength
level
(1)
and
certificate
authentication
is
the
second
(stronger)
authentication
level
(2).
v
Users
must
authenticate
using
forms
authentication
or
stronger
to
access
the
following
protected
resource
(a
WebSEAL
junction):
/WebSEAL/hostA/junction
v
Users
must
authenticate
using
certificate
authentication
to
access
the
following
protected
resource
(an
application):
/WebSEAL/hostA/junction/applicationA
To
implement
this
policy,
the
following
configuration
steps
must
take
place.
1.
Modify
the
WebSEAL
configuration
file
to
grant
forms
authentication
an
authentication
strength
of
1
and
certificate
authentication
a
strength
of
2:
[authentication-levels]
level
=
unauthenticated
level
=
password
level
=
ssl
2.
Create
a
POP
for
authentication
level
1
(forms
authentication).
124
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide