Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

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.