enrolepolicies.properties

enrolepolicies.properties

The enrolepolicies.properties file provides standard and custom settings that support the functions of the provisioning policy.
Functions supported by this properties file includes.

Specifying Java™ classes to process provisioning policy conflicts with join directives
Specifying default and non-default join directive caching timeouts
Declaring policy attributes to be ignored during policy compliance validation

A join directive is a set of rules used to determine how attributes are handled when a provisioning policy conflicts with another. Join directives use logical constructs to resolve conflicts. Examples include combining all policy attributes (union), with only common attributes (intersection), and resolving conflicts with Boolean AND or OR logic..
There are 12 types of join directives that you can use. Provisioning policy join directives take effect when more than one provisioning policy is defined for the same user (or group of users) for the same target service, service instance, or service type.. Custom join directives can be defined by writing a custom Java class, adding it to your class path, and then providing the fully qualified Java class name in the policy configuration GUI. If you extend or replace one of the existing join directive classes, you must add the custom property key and value to the enrolepolicies.properties file. For example if you developed a new class (com.abc.TextualEx) to replace the existing class for textual joins, the registration line is as follows:
provisioning.policy.join.Textual= com.abc.TextualEx

Properties used to configure IBM Security Identity Manager policies.

Join directive classes

provisioning.policy.join.PrecedenceSequence=com.ibm.itim.policy.join.PrecedenceSequence
provisioning.policy.join.Boolean=com.ibm.itim.policy.join.Boolean
provisioning.policy.join.Bitwise=com.ibm.itim.policy.join.Bitwise
provisioning.policy.join.Numeric=com.ibm.itim.policy.join.Numeric
provisioning.policy.join.Textual=com.ibm.itim.policy.join.Textual
provisioning.policy.join.Textual.AppendSeparator=<<<>>>
provisioning.policy.join.Multivalued=com.ibm.itim.policy.join.Multivalued

Do not modify these property keys and values.

Each property key specifies a Java class. It can be used to process the logic of a join directive that is required to resolve a provisioning policy conflict.

Append separator characters

provisioning.policy.join.Textual.AppendSeparator

Specifies the character used by the textual join directive Java class to separate individual values of a multi-value attribute.

Example.
provisioning.policy.join.Textual.AppendSeparator=<<<>>>

Join directive cache timeouts

provisioning.policy.join.defaultCacheTimeout

Timeout interval [in seconds] between refreshes of the cache that stores default join directive cache values..

The default is 86400 seconds, which is 24 hours..

Example (default).
provisioning.policy.join.defaultCacheTimeout=86400

provisioning.policy.join.overridingCacheTimeout

Timeout interval [in seconds] between refreshes of the cache that stores non-default join directive values..

The default is 300 seconds, which is 5 minutes..

Example.
provisioning.policy.join.overridingCacheTimeout=300

Account attributes ignored by policy compliance validation

Excluded generic attributes (default value=1):

nonvalidateable.attribute.eraccountcompliance
nonvalidateable.attribute.eracl
nonvalidateable.attribute.eraccountstatus
nonvalidateable.attribute.erauthorizationowner
nonvalidateable.attribute.erglobalid
nonvalidateable.attribute.erhistoricalpassword
nonvalidateable.attribute.erisdeleted
nonvalidateable.attribute.erlastmodifiedtime
nonvalidateable.attribute.erlogontimes
nonvalidateable.attribute.ernumlogons
nonvalidateable.attribute.erparent
nonvalidateable.attribute.erpassword
nonvalidateable.attribute.erservice
#nonvalidateable.attribute.eruid
nonvalidateable.attribute.objectclass
nonvalidateable.attribute.owner
nonvalidateable.attribute.ercreatedate
nonvalidateable.attribute.erlaststatuschangedate
nonvalidateable.attribute.erpswdlastchanged
nonvalidateable.attribute.erlastaccessdate
nonvalidateable.attribute.ernumlogonattempt

Excluded Windows Server attributes:

nonvalidateable.attribute.erntpasswordexpired nonvalidateable.attribute.erntuserbadpwdcount nonvalidateable.attribute.erntlockedout

Declares account attributes that are to be ignored during policy compliance validation. This exclusion list reduces overhead during compliance validation. It also reduces the risk of system failure that can be caused by attributes that cannot logically be resolved during validation.

Partition size

policy.partition.size

To analyze many persons during a policy change event without incurring transaction timeouts, you must break apart or partition the total number of affected persons. It is done, not for starting the concurrent policy analysis, but strictly to avoid waiting in a single database transaction for all persons to be processed. Creating multiple transactions or quickly partitioning the total number of users diminishes the chance of any (smaller) transactions to exceed the transaction timeout value. When a Application server cluster is used with IBM Security Identity Manager, it is helpful to note that partitioning operation itself is not clustered. It is done on the same Application server node which receives the policy change request.
Number of persons or accounts to be evaluated in each thread during high volume policy analysis. High volume policy analysis occurs when a policy change or a service enforcement level change affects a large group of persons or accounts. A larger partition size results in fewer threads. A smaller partition size results in more executed threads in parallel, which requires more memory.

Example (default).
policy.partition.size=2500

policy.message.size

Number of persons that are analyzed as part of policy change within a single JMS message. Since Application server polled and reuses threads, the JMS mechanism queues the individual units of analysis work for all assigned Application server threads or message consumers. It is likely that during large policy changes that affect large numbers of people, all JMS consumer threads are busy processing policy analysis and enforcement; the queue for each thread is saturated with more messages to process.

Example (default).
policy.message.size=25

Additional properties

policy.analysisservicebatch.size

Maximum number of services to be analyzed in each policy analysis message. This property is useful during policy/person analysis when a person has many accounts. To prevent system from running into OOM or hung threads this property can be tuned.
By default, the property is commented out and an internal hardcoded value of 100 is applied. This default 100 service per batch is found to be optimal for environments that has users who own up to 50 K accounts across multiple platforms.

Example (default).
policy.analysisservicebatch.size=100

policy.service.selection.maxsearch.size

This property is used to return the specified number of Persons affected by the policy. It also checks whether the policy references any Person of given user class in any one of its memberships.
The number is for person search, which is per policy, and thus additive based on the policies involved. It prevents an accidental explosion of the server's JVM with an OOM. By default, the property has an internal hardcoded value of 10000. This property is used while evaluating a collection of service move operations for persons affected by adding a host selection policy. It is also used while evaluating a service selection script.

Example (default).
policy.service.selection.maxsearch.size=10000

policy.cleanup.commitFrequency

Number of rows that are to be deleted as a batch from database tables while the policy analysis data is cleaned up..
The value of this property if set to 0, commits database updates only at the end when the entire cleanup activity is completed.
If this property value is set to any number greater than 0, the commit is done when the number of uncommitted database updates are equal to this set value. If negative or non-integer value is specified, then default value of 0 is used. The default value of the property is 0 and suggested values are multiples of 1000 (Ex: 25000).

Example (default).
policy.cleanup.commitFrequency=0

During a provisioning policy preview operation, IBM Security Identity Manager evaluates and joins other dependent provisioning policies that are applicable to a user. Performing a lookup for the policy and its dependent data in directory server and parsing it for each user can hamper performance. IBM Security Identity Manager caches the already parsed policies for better performance.
Following caches are created.

Policy Cache: Maintains a mapping of provisioning policy DNs and policy objects in cache with policy DN as the key.
RoleDN Cache: Maintains a mapping of Organizational Role DN and a set of provisioning policy DNs in cache with Organizational Role DN as the key.
ServiceDN Cache: Maintains a mapping of Service DN and a set of provisioning policy DNs in cache with Service DN as the key.

The greater number of data objects in the cache, the greater is the consumption of memory. The following three properties help to tune the caches by defining the maximum number of policies, service DNs, and role DNs to be cached.

Provisioning policy cache size

policy.policiescache.size

Number of provisioning policies to be cached in Policy cache for each provisioning policy preview request. For better performance, the size can be set to number of policies in the Organization.

Example (default).
policy.policiescache.size=100

Organizational Role DN cache size

policy.roledncache.size

Number of role DNs to be cached in RoleDN cache for each provisioning policy preview request. For better performance, the size can be set to number of roles in the Organization.

Example (default).
policy.roledncache.size=100

Service DN cache size

policy.servicedncache.size

Number of Service DNs to be cached in ServiceDN cache for each provisioning policy preview request. For better performance, the size can be set to number of services in the Organization.

Example (default).
policy.servicedncache.size=100

Parent topic: Supplemental property files

Join directive classes
provisioning.policy.join.PrecedenceSequence=com.ibm.itim.policy.join.PrecedenceSequence provisioning.policy.join.Boolean=com.ibm.itim.policy.join.Boolean provisioning.policy.join.Bitwise=com.ibm.itim.policy.join.Bitwise provisioning.policy.join.Numeric=com.ibm.itim.policy.join.Numeric provisioning.policy.join.Textual=com.ibm.itim.policy.join.Textual provisioning.policy.join.Textual.AppendSeparator=<<<>>> provisioning.policy.join.Multivalued=com.ibm.itim.policy.join.Multivalued
	Do not modify these property keys and values. Each property key specifies a Java class. It can be used to process the logic of a join directive that is required to resolve a provisioning policy conflict.

Append separator characters
provisioning.policy.join.Textual.AppendSeparator
	Specifies the character used by the textual join directive Java class to separate individual values of a multi-value attribute. Example. provisioning.policy.join.Textual.AppendSeparator=<<<>>>

Join directive cache timeouts
provisioning.policy.join.defaultCacheTimeout
	Timeout interval [in seconds] between refreshes of the cache that stores default join directive cache values.. The default is 86400 seconds, which is 24 hours.. Example (default). provisioning.policy.join.defaultCacheTimeout=86400
provisioning.policy.join.overridingCacheTimeout
	Timeout interval [in seconds] between refreshes of the cache that stores non-default join directive values.. The default is 300 seconds, which is 5 minutes.. Example. provisioning.policy.join.overridingCacheTimeout=300

Account attributes ignored by policy compliance validation
Excluded generic attributes (default value=1):
	nonvalidateable.attribute.eraccountcompliance nonvalidateable.attribute.eracl nonvalidateable.attribute.eraccountstatus nonvalidateable.attribute.erauthorizationowner nonvalidateable.attribute.erglobalid nonvalidateable.attribute.erhistoricalpassword nonvalidateable.attribute.erisdeleted nonvalidateable.attribute.erlastmodifiedtime nonvalidateable.attribute.erlogontimes nonvalidateable.attribute.ernumlogons nonvalidateable.attribute.erparent nonvalidateable.attribute.erpassword nonvalidateable.attribute.erservice #nonvalidateable.attribute.eruid nonvalidateable.attribute.objectclass nonvalidateable.attribute.owner nonvalidateable.attribute.ercreatedate nonvalidateable.attribute.erlaststatuschangedate nonvalidateable.attribute.erpswdlastchanged nonvalidateable.attribute.erlastaccessdate nonvalidateable.attribute.ernumlogonattempt
Excluded Windows Server attributes:
	nonvalidateable.attribute.erntpasswordexpired nonvalidateable.attribute.erntuserbadpwdcount nonvalidateable.attribute.erntlockedout
	Declares account attributes that are to be ignored during policy compliance validation. This exclusion list reduces overhead during compliance validation. It also reduces the risk of system failure that can be caused by attributes that cannot logically be resolved during validation.
Partition size
policy.partition.size
	To analyze many persons during a policy change event without incurring transaction timeouts, you must break apart or partition the total number of affected persons. It is done, not for starting the concurrent policy analysis, but strictly to avoid waiting in a single database transaction for all persons to be processed. Creating multiple transactions or quickly partitioning the total number of users diminishes the chance of any (smaller) transactions to exceed the transaction timeout value. When a Application server cluster is used with IBM Security Identity Manager, it is helpful to note that partitioning operation itself is not clustered. It is done on the same Application server node which receives the policy change request. Number of persons or accounts to be evaluated in each thread during high volume policy analysis. High volume policy analysis occurs when a policy change or a service enforcement level change affects a large group of persons or accounts. A larger partition size results in fewer threads. A smaller partition size results in more executed threads in parallel, which requires more memory. Example (default). policy.partition.size=2500
policy.message.size
	Number of persons that are analyzed as part of policy change within a single JMS message. Since Application server polled and reuses threads, the JMS mechanism queues the individual units of analysis work for all assigned Application server threads or message consumers. It is likely that during large policy changes that affect large numbers of people, all JMS consumer threads are busy processing policy analysis and enforcement; the queue for each thread is saturated with more messages to process. Example (default). policy.message.size=25

Additional properties
policy.analysisservicebatch.size
	Maximum number of services to be analyzed in each policy analysis message. This property is useful during policy/person analysis when a person has many accounts. To prevent system from running into OOM or hung threads this property can be tuned. By default, the property is commented out and an internal hardcoded value of 100 is applied. This default 100 service per batch is found to be optimal for environments that has users who own up to 50 K accounts across multiple platforms. Example (default). policy.analysisservicebatch.size=100

policy.service.selection.maxsearch.size
	This property is used to return the specified number of Persons affected by the policy. It also checks whether the policy references any Person of given user class in any one of its memberships. The number is for person search, which is per policy, and thus additive based on the policies involved. It prevents an accidental explosion of the server's JVM with an OOM. By default, the property has an internal hardcoded value of 10000. This property is used while evaluating a collection of service move operations for persons affected by adding a host selection policy. It is also used while evaluating a service selection script. Example (default). policy.service.selection.maxsearch.size=10000

policy.cleanup.commitFrequency
	Number of rows that are to be deleted as a batch from database tables while the policy analysis data is cleaned up.. The value of this property if set to 0, commits database updates only at the end when the entire cleanup activity is completed. If this property value is set to any number greater than 0, the commit is done when the number of uncommitted database updates are equal to this set value. If negative or non-integer value is specified, then default value of 0 is used. The default value of the property is 0 and suggested values are multiples of 1000 (Ex: 25000). Example (default). policy.cleanup.commitFrequency=0

During a provisioning policy preview operation, IBM Security Identity Manager evaluates and joins other dependent provisioning policies that are applicable to a user. Performing a lookup for the policy and its dependent data in directory server and parsing it for each user can hamper performance. IBM Security Identity Manager caches the already parsed policies for better performance. Following caches are created. Policy Cache: Maintains a mapping of provisioning policy DNs and policy objects in cache with policy DN as the key. RoleDN Cache: Maintains a mapping of Organizational Role DN and a set of provisioning policy DNs in cache with Organizational Role DN as the key. ServiceDN Cache: Maintains a mapping of Service DN and a set of provisioning policy DNs in cache with Service DN as the key. The greater number of data objects in the cache, the greater is the consumption of memory. The following three properties help to tune the caches by defining the maximum number of policies, service DNs, and role DNs to be cached.

Provisioning policy cache size
policy.policiescache.size
	Number of provisioning policies to be cached in Policy cache for each provisioning policy preview request. For better performance, the size can be set to number of policies in the Organization. Example (default). policy.policiescache.size=100

Organizational Role DN cache size
policy.roledncache.size
	Number of role DNs to be cached in RoleDN cache for each provisioning policy preview request. For better performance, the size can be set to number of roles in the Organization. Example (default). policy.roledncache.size=100

Service DN cache size
policy.servicedncache.size
	Number of Service DNs to be cached in ServiceDN cache for each provisioning policy preview request. For better performance, the size can be set to number of services in the Organization. Example (default). policy.servicedncache.size=100