Making better use of pedagogical innovations

Provisioning policies define the level of access a user is granted to a resource. In order to create a provisioning policy, you must define:

򐂰 Membership: Who is allowed access.

򐂰 Entitlements: What resources are provided to users.

When creating a provisioning policy, keep in mind that complicated provisioning policies can result in complicated directory and database queries with poor performance. Policies with a small numbers of roles and services will perform best.

Also, the scope of the provisioning policy depends on the position in the org tree and indicates whether to cover services in the same level of the business unit or the subtree of the business unit.

Membership

Provisioning policies are based on the following membership options:

򐂰 User membership to the organization (all people). In this case, any person registered in Tivoli Identity Manager will have access to the provisioned service.

򐂰 User membership to one or more organizational roles. In this case, a person must belong to a specific organizational role before they will be granted access to the provisioned service.

򐂰 User membership to no organizational role (others). This case enables you to provide services to people that do not belong to any organizational roles.

Certain services and organizational roles can have strict provisioning policies, such as those policies created for HR applications. However, policies created for services such as e-mail might not be as strict, especially because every user in the company typically requires access to e-mail.

Entitlements

An entitlement is part of a provisioning policy that determines which users are allowed to have access to certain resources. Entitlements are used to determine:

򐂰 What services are provided to the users defined in the policy membership.

򐂰 Whether the accounts are provisioned manually or automatically.

򐂰 How the account is configured (what attributes and values it has, such as default groups and home directory).

An entitlement in the provisioning policy supports different types of service targets, including all services, services of same type, services defined by service selection policy, or specific service instances.

Entitlements can be either automatic or manual. If a provisioning policy uses an automatic entitlement, a user will automatically be provisioned with services when the user meets the membership requirements. If a provisioning policy uses a manual entitlement, a Tivoli Identity Manager system administrator needs to take action to provision the user with the respective services.

Each service targeted by a provisioning policy can also have a workflow

attached. A workflow is used to introduce additional processing before access is provisioned. A workflow can determine an approval process for a particular

Chapter 4. Implementation 121 service or set of services. For more information about workflows, see 4.6,

“Workflows” on page 128.

Entitlement target type

Each provisioning policy is responsible for defining who gets accounts on one or more services. These services are called targets. The targets of a provisioning policy entitlement determine which accounts the policy members are entitled to receive.

There are four ways to configure the target type of a provisioning policy entitlement:

򐂰 All services, meaning that any service is available to a person that meets the membership requirements.

򐂰 By service profile, meaning that any services of a particular type are available to a person that meets the membership requirements.

򐂰 By a specific service instance name.

򐂰 By a service selection policy, which is a policy that determines a specific service based on the user information.

It is possible to test a provisioning policy by using the Preview button and check the results in order to avoid any undesirable changes to accounts and managed targets. The preview feature displays all account errors (non-compliances) and what actions would have taken place.

You can select one of two types of provisioning policy enforcements to check during the simulation:

򐂰 Changes only

Perform a provisioning policy simulation to preview the results for only the changes you are about to make.

򐂰 Entire policy

Perform a provisioning policy simulation to preview the results for all computed enforcement actions for the entire policy.

It is possible to save a draft of a provisioning policy. This way, you can avoid an immediate execution in a production environment in order to minimize the risks of a misconfigured provisioning policy. To determine the impact of a new or

changed provisioning policy, a provisioning policy simulation can be run against a draft or a committed provisioning policy.

Let us take a look at a best practice approach:

1. Make changes to or create a new provisioning policy, and save it as a draft.

2. Run a provisioning policy simulation against the draft provisioning policy.

3. Commit the provisioning policy if everything works as expected. The action causes the draft to be deleted automatically.

4. Delete or reconfigure the draft if the simulation showed undesirable effects.

Sometimes, users have several provisioning policies that apply to them. When two or more provisioning policies are applied to the same user, a join directive defines how to handle attribute values from different policies.

Entitlements parameters

Each entitlement in a provisioning policy is also responsible for determining how access to a particular service is configured by defining parameters for a service.

For example, you can determine if a user is a member of a group on a particular resource, where their home directory is created, and the level of access privilege.

The following parameter types are valid:

򐂰 Constant value

򐂰 Null

򐂰 JavaScript

򐂰 Regular expression

The provisioning parameters in an entitlement can be defined statically or dynamically.

Parameters are defined statically by selecting the constant parameter type and specifying literal values, such as strings or integers. For example, an attribute can be defined as Domain Users or Power Users.

A parameter value that is defined dynamically can be based on a JavaScript function that can retrieve data from the Tivoli Identity Manager directory server. A range of values can be defined using a regular expression.

Parameters can also be specified as null, indicating that the parameter does not have a value. This situation is equivalent to having a JavaScript parameter type with a value of return null.

Provisioning parameters for single-valued attributes can be based only on JavaScript code or a constant. The provisioning parameters of a multi-valued attribute can use a constant, JavaScript code, or regular expression for their values. However, a regular expression can be used only for provisioning parameter enforcement of the Allowed or Excluded type.

Policy enforcement

Provisioning policies are very important to support security compliance. Tivoli Identity Manager evaluates all account and access requests based on the

Chapter 4. Implementation 123 provisioning policy to identify accounts and access that are not authorized and take appropriate actions to handle non-compliant account and access. Based on the enforcement configuration on the service, Tivoli Identity Manager can either:

򐂰 Mark the account or access as non-compliant

򐂰 Suspend the account

򐂰 Alert administrator to revoke disallowed privilege, or

򐂰 Automatically correct the account or access and make it compliant.

The advanced provisioning parameter list also contains enforcement fields that enable you to specify an enforcement rule for the attributes. Enforcement rules determine which attributes are required for an account and which values are valid for the attribute. Attribute enforcement is active only if at least one provisioning parameter is defined. If no parameters are defined, all attributes are implicitly allowed. An enforcement rule can have one of the following values:

򐂰 Default

򐂰 Mandatory

򐂰 Optional

򐂰 Excluded

A null provisioning parameter value has a special meaning in Tivoli Identity Manager:

򐂰 A null mandatory parameter value means that all values on the corresponding attribute of a new or existing account are disallowed. Any existing attribute values will be automatically removed.

򐂰 A null default for optional parameter value means that all new values or changes to existing values on the corresponding attribute of a new or existing account are disallowed, but currently set values will not be removed

automatically. Any currently set value can be removed manually.

򐂰 A null excluded parameter means that all attribute values are allowed on the corresponding attribute of a new or existing account.

Global policy enforcement is the manner in which the Tivoli Identity Manager system globally allows or disallows accounts that violate provisioning policies.

When a policy enforcement action is global, the policy enforcement for any service is defined by the default configuration setting. However, if a service has a

Note: Each service targeted by a provisioning policy can also have a workflow attached. Workflows are used to introduce additional processing before access is provisioned. Workflows can initiate an approval process for a particular service or set of services. We present more information in 4.6,

“Workflows” on page 128.

specific policy enforcement setting, that setting takes precedence over the global enforcement setting.

Provisioning policy join directive

Provisioning policy join directives define how Tivoli Identity Manager manages attributes when provisioning policies conflict. Provisioning policy join directives take affect when there are multiple provisioning policies defined for the same users (or groups of users) on the same target service, service instance, or service type. Unlike the configuration policy itself, the join directive configuration and customization is defined under a separate part of the administration

interface, using Configure System→ Configure Policy Join Behaviors.

The entitlement target type also plays a role in how policy join directives resolve which entitlement is granted when conflicts arise between policies. When two or more policies grant similar entitlements, the more specific entitlement takes precedence. For example, if one provisioning policy includes an entitlement defined to grant access to a type of service (that is, AIX named AIX), and the second policy includes an entitlement defined to grant access to a specific instance of that service (that is, AIX105), the more specific entitlement takes precedence.

Tivoli Identity Manager provides several types of join directives.

򐂰 Union (the default for Multivalued string or number type of attributes)

򐂰 Intersection

򐂰 Append

򐂰 And

򐂰 Or (the default for Single-valued boolean string type of attribute)

򐂰 Highest (the default for Single-valued integer type of attribute)

򐂰 Lowest

򐂰 Average

򐂰 Bitwise_Or (the default for Singled-valued bitstring type of attribute)

򐂰 Bitwise_And

򐂰 Precedence_Sequence

򐂰 Priority (the default for Single-valued string type of attribute)

The provisioning policy with the lowest priority number takes precedence over a similar policy that grants the same entitlement with a higher priority number.

If conflicting policies have the same priority, the first policy found by the system is used.

In addition, Custom join directives can be defined (using Java) to change the built-in join logic completely.

Chapter 4. Implementation 125 For a better understanding of priorities and join directives, see the examples provided in the IBM Tivoli Identity Manager Information Center:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=

/com.ibm.itim.doc/ref/ref_ic_policy_joindir_examples.htm