Chapter 4. Configuration and customization 99
򐂰 password-spaces {yes|no|unset}
Sets the policy of whether spaces are allowed in passwords. The default
value is unset.
򐂰 tod-access {{anyday|weekday|day_list}:{anytime|time_spec-time_spec}
[:{utc|local}]|unset}}
Sets the time of day access policy.
򐂰 user user_name
Specifies the user whose policy information is to be set. If this option is not
specified, the general policy is set.
For any given policy, if a user has a specific policy applied, this specific policy
takes precedence over any general policy that might also be defined. The
precedence applies regardless of whether the specific policy is more or less
restrictive than the general policy set.
Password strength default values
Table 4-1 lists the password strength policies and the default values.
Table 4-1 Default values for password strength policy
To display some of the user policy settings use the following command:
pdadmin > policy get options [–user user_name]
If the user name is omitted, the returned value gives the settings for all users at a
global level. The options are the same as in the policy set command.
4.1.4 Security policy
The goal of any security policy is to adequately protect business assets and
resources with a minimal amount of administrative effort. First, you must define
what resources should be protected. These could be any types of data objects
such as files, directories, network servers, messages, databases, or Web
resources. Then, you must decide what users and groups of users should have
access to these protected resources. You also need to decide what type of
Policy Default Value
min-password-length 8
min-password-alphas 4
min-password-non-alphas 1
max-password-repeated-chars 2
password-spaces not set
100 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
access should be permitted to these resources. Finally, you must apply the
proper security policy on these resources to ensure that only the right users can
access them (we already explained that resources are represented as objects in
the Policy Server object space).
Access to objects within a domain is controlled by applying a security policy to
the container and resource objects in the protected object space. To secure
network resources in a protected object space, each object must be protected by
a security policy. A security policy can be explicitly applied to an object or
inherited from objects above it in the hierarchy. You need to apply an explicit
security policy in the protected object space only at those points in the hierarchy
where the rules must change.
Adopting an inherited security scheme can greatly reduce the administration
tasks for a domain. The power of security policy inheritance is based on the
following principle:
Any object without an explicitly attached security policy inherits the policy of
its nearest container object with an explicitly set security policy. The
inheritance chain is broken when an object has an explicitly attached security
policy.
Security policy inheritance simplifies the task of setting and maintaining access
controls on a large protected object space. In a typical object space, you need to
attach only a few security policies at key locations to secure the entire object
space. Therefore, it is called a
sparse security policy model.
Security policy is defined using a combination of:
򐂰 Access control lists (ACLs)
An access control list specifies the predefined actions that a set of users and
groups can perform on an object. For example, a specific set of groups or
users can be granted
read access to the object.
򐂰 Protected object policies (POPs)
A protected object policy specifies access conditions associated with an
object that affect all users and groups. For example, a
time-of-day restriction
can be placed on the object that excludes all users and groups from
accessing the object during the specified time.
򐂰 Authorization rules
An authorization rule specifies a complex condition that is evaluated to
determine whether access will be permitted. The data used to make this
decision can be based on the context of the request, the current environment,
or other external factors. For example, a request to modify an object
more
than five times in an 8-hour period
could be denied.

Get Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0 now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.