sim planning

Planning

��

ii Planning

Contents

Planning . . . . . . . . . . . . . . 1People planning . . . . . . . . . . . . . 1

Identity feed planning . . . . . . . . . . 2Password policy and password synchronizationplanning. . . . . . . . . . . . . . . 4

Security planning . . . . . . . . . . . . . 4Initial security conditions after installation . . . 4Group management issues . . . . . . . . . 5Access control item management issues . . . . 11

Role planning . . . . . . . . . . . . . 16Access control models . . . . . . . . . . 16Access provisioning models . . . . . . . . 17Organizational roles and access provisioning . . 17Static and dynamic roles . . . . . . . . . 19Roles in the organization tree . . . . . . . 19

Planning an organization tree . . . . . . . . 20Organization tree models . . . . . . . . . 20Model example . . . . . . . . . . . . 21Scope of governing entities in the organizationtree . . . . . . . . . . . . . . . . 23

Workflow planning . . . . . . . . . . . . 26Operation workflows . . . . . . . . . . 26User account and access request workflows . . 30Workflow elements . . . . . . . . . . . 33Workflow data . . . . . . . . . . . . 40Workflow participants . . . . . . . . . . 44Notification of failed workflow requests . . . . 46

Index . . . . . . . . . . . . . . . 47

iii

iv Planning

Planning

Planning is an activity in which you make decisions that affect one or moresubsequent activities.

In this documentation set, you will find preinstallation planning covered in theInstalling topic and in the Installation Guide. There, the planning informationhelps IT architects and various administrators select and implement multiplenode server environments comprised of one or more product installations.

Aside from the planning that precedes product installation, system administratorsand others encounter various decisions that are smaller in scale, but can haveramifications if not well planned. Those are the kind of decisions outlined underthis Planning topic.

People planningFor the people in your organization, you can plan how to import identity recordsthat create IBM® Tivoli® Identity Manager users, and how to provide theirpasswords.

The following table includes examples of initial conditions and firstimplementation steps that administrators might take.

Table 1. Summary of potential user planning issues

Topic Initial condition and questions Example implementation steps

Identities One administrator accountnamed itim manager exists,with an initial password ofsecret.

v Which identity recordsrequire IBM Tivoli IdentityManager user IDs?

v Does your earlyimplementation need todefine additionaladministrators?

At a minimum, create oneidentity to test each group thatIBM Tivoli Identity Managerprovides. Additionally, create analternate administrative user IDto guard against accidental lossof access.

Import identity records A global identity policy exists.

v Which data format does yourorganization plan to use toimport identity records?

v Are the attributes that theglobal identity policyspecifies appropriate for youruse?

Determine which identity feedto use, and ensure that theappropriate attributes arespecified in an identity policy.

For most organizations,manually loading user data isnot a practical method to definea large number of users.

1

Table 1. Summary of potential user planning issues (continued)


Policies (password,identity)

Password policy or forgottenpassword specifications do notexist. Password synchronizationis on.

The default identity policy isbased on the uid attribute of theuser. If the uid attribute has anull value, the identity policyconcatenates the initial of aperson’s first name with theperson’s last name.

What are your organization’srequirements for a passwordpolicy, challenge-responseauthentication, and identitypolicy?

Determine your organization’spassword policy,challenge-responseauthentication, and identitypolicy, and then specify thesepolicies.

Identity feed planningPlanning is required before you populate IBM Tivoli Identity Manager with usersby importing the identity records from your human resources repository or fromother sources. An identity feed is the process of loading identity records into IBMTivoli Identity Manager.

The identity feed process includes the tasks in Figure 1 on page 3.

2 Planning

The following identity feed tasks are basic:1. Prepare the person data for the initial identity feed.

Determine the best authoritative data sources, such as the human resources(HR) repository. You determine what information to use as the requiredattributes of a person. For example, data that indicates a person’s title might berequired to correctly assign a role to that person as a IBM Tivoli IdentityManager user.Minimally, IBM Tivoli Identity Manager requires the following information tomanage an identity:v Common name (LDAP CN)v Last name (LDAP SN)

Note: Your planning also needs to anticipate the effect of missing informationin the user record. For example, if the record that you feed into IBM TivoliIdentity Manager does not include an e-mail address for the user, the user doesnot receive a password for a new account in an e-mail. The user then musteither call the help desk or contact the manager.

2. Determine the format to use to load the data.For example, you might determine to populate IBM Tivoli Identity Managerpeople registry by reconciling using one of the following formats:v Comma-Separated Value (CSV) identity feedv DSML identity feedv AD OrganizationalPerson identity feedv INetOrgPerson (LDAP) identity feedv IDI data feed

3. Create a service for the selected data format.

Figure 1. Obtaining identity data

Planning 3

4. If necessary, adjust an identity policy to use in reconciling the repositoryidentity records.

5. Reconcile the service to load the identity information.After the initial identity feed is completed, ensure that all the identities areloaded correctly. You might see inconsistencies in person and account data. Theamount of cleanup depends on how well your organization prepares theidentity data for the initial load.

6. When the initial reconciliation completes successfully, create accounts on theresources that your organization wants to manage using IBM Tivoli IdentityManager.

Password policy and password synchronization planningDetermine the unique requirements for the rules that passwords for a service mustmeet. These requirements include length and type of characters allowed anddisallowed, and whether to keep password synchronization, which is enabled bydefault.

To ensure that the correct users have access, create a password strength rule.

Password synchronization allows a user to change one password that is synchronizedwith the passwords for all the accounts that the user has on other resources thatIBM Tivoli Identity Manager manages. If you use password synchronization, youneed to plan whether to use a single password policy or use several passwordpolicies. A single password policy enforces the policy on all accounts that a userowns. If several password policies exist, each policy might apply to a subset ofaccounts that a user owns.

Security planningAfter installing IBM Tivoli Identity Manager, you must take additional steps toplan how to grant and manage user access to resources.

Initial security conditions after installationThe initial security conditions of predefined groups, views, and access controlitems might require that you take additional steps to grant and manage user accessto resources.

Table 2 describes some of the initial conditions and first security planning stepsthat administrators might take after installing IBM Tivoli Identity Manager.

Table 2. Example planning issues


Groups All default groups initially haveno members, except for theSystem Administrator group,which contains one user whoseaccount is named itim manager.

Which individuals in yourorganization need to belong inwhich default groups? Do thesegroups meet your site needs, ordo you need to createadditional, customized groups?

Complete one or more of thesetasks:

v Specify an additional systemadministrator to ensure thatyou do not accidentally loseaccess to IBM Tivoli IdentityManager.

v Create additional, customizedgroups, and related viewsand access control items.

4 Planning

Table 2. Example planning issues (continued)


Group settings insecurity properties

The checkbox to automaticallypopulate IBM Tivoli IdentityManager groups is disabledimmediately after installation. Ifyou feed identity records intoIBM Tivoli Identity Manager,you must manually populatemembers into predefinedgroups.

As administrator, you canspecify the option toautomatically populate IBMTivoli Identity Manager groups.

Views All default groups have a set ofpermitted tasks that memberscan use.

As administrator, you canspecify the view that a usersees of the user’s own accountsand information, as well asother tasks in the user interface.

Access control items Initially, all users have readaccess to their personal profile.Other default access controlitems apply, for example, to theowner of a service and themanager of a subordinate.

What are your organization’srequirements to expand orrestrict access? Do you wantenable users to modify all oronly some fields in a personalprofile? Which users shouldmanage delegation schedules?

Specify one or more accesscontrol items that restrict orexpand access.

Forms Initially, forms contain a set ofattributes for each availablecategory. The set of attributescan be configured using theform designer. What attributesare required in your businessenvironment to appear on theform for each category?

If you customize groups, views,and related access control itemsafter initial installation, youmight also want to show orhide some fields that match theexpanded or limitedpermissions you specifiedduring customization.

As administrator, you cancustomize the forms using theform designer to reflect theattributes that need to appearor be hidden on the form.

Group management issuesManaging groups requires your attention to membership retention in groups, tooverlapping views if membership occurs in multiple groups, and to the scope ofpredefined and customized groups.

Planning 5

Automatic group accountsFor members of some predefined groups, you can configure IBM Tivoli IdentityManager to automatically put the IBM Tivoli Identity Manager accounts of newlynamed members in the default group. Automatic assignment does not apply tocustomized groups.

For example, newly named service owners who have IBM Tivoli Identity Manageraccounts can automatically receive accounts in the default Service Owner group.Additionally, the accounts of newly named managers are automatically put in thedefault Manager group. For example, this can occur when you create or modify auser who is a subordinate, specifying the manager of the user.

The automatic action is enabled or disabled immediately. You do not need torestart IBM Tivoli Identity Manager.

Upgrading IBM Tivoli Identity Manager from a previous release retains the groupmembership from the previous release. All groups that have organization treeaccess are migrated to the default Help Desk Assistant view.

To populate the default groups that Version 5 of IBM Tivoli Identity Manager, youmust manually assign members.

Group membershipA user can be a member of more than one group, obtaining membership in agroup either explicitly or by reference.

An administrator, or another user with the appropriate permissions, can explicitlyassign a user to a group. If automatic population of groups is enabled, you canalso cause a user to become a group member by referencing the user as themanager of another user or as the owner of a service. You can assign groupmembers either by using the Manage Group tasks on the user interface portfolio,or by editing the IBM Tivoli Identity Manager account profile of a specific user.You must ensure that a member of multiple groups does not receive accidentalaccess to some tasks that fall outside the intended scope for the user.

Not all users gain automatic membership in groups, as described in Table 3.

Table 3. Assignment to groups

User given this relationship Automatically assigned to default group*

Manager of a user Manager

Supervisor of a business unit Not automatic

Owner of a service Service owner

*If the property is enabled to automatically populate identity manager groups.

Additional conditions apply:v Having no IBM Tivoli Identity Manager account does not prevent a person from

being specified as service owner or supervisor. However, no IBM Tivoli IdentityManager account is created or put in a default group. If that service owner orsupervisor later obtains a IBM Tivoli Identity Manager account, the account isnot automatically put in a default group. You must create or modify a service ora user who is a subordinate.

v A person who has a IBM Tivoli Identity Manager account becomes a user.Removing the user as manager of all subordinates, or removing the user as

6 Planning

owner of all services, does not remove the IBM Tivoli Identity Manager accountor the user from a default group, such as the Manager group. Updating themanager attribute of a subordinate’s personal profile to reference a differentmanager, or to reference no one, does not remove the previously referenced userfrom the Manager group. You can explicitly remove a user from the Managergroup. The member is automatically removed from the group only when theuser record is deleted.

v If you explicitly remove the user from a group, and then update a user’spersonal profile again to reference the user as their manager, the referenced useragain becomes a member in the Manager group.

Multiple groups and viewsIf a user is a member of multiple groups, the user has a merged view of all of thetasks that are provided to both groups, even if one of the groups does not grantaccess to the task.

You need to coordinate the views that users see, when they have membership inmultiple groups. One group to which they belong might permit a task, and anothergroup might not. If a task is permitted in any view, that permission takesprecedence. For example, if a task is permitted in the view that one group has, auser in that group can use the task, even if the user is also member of a secondgroup with a view that excludes the same task.

Scope of groupsThe default tasks and associated access control items set the scope of activities formembers of predefined and customized groups.

Scope of a customized group:

A major business reason to customize groups is to increase or limit the scope ofactivities for group members. You might begin by examining the scope that thepredefined groups have.

To enable tasks for customized groups of authorized users, define a new groupand a view of tasks for group members. Additionally, specify one or more accesscontrol items to grant specific operations and permissions to each group member.You can also change the form for the user interface.

For example, your business needs might require:v An end-user group with expanded permissions and activities that a subset of

users can exercise.v A supervisor group with expanded privileges and activities, because the default

Manager group has a relatively limited scope.v Service owners or Help Desk Assistant groups with more limited privileges and

tasks, because the default groups for service owners and help desk assistantshave a relatively large scope.

Note: You cannot create an additional group for system administrators.

End users with no membership in a default group:

An end user who has no membership in a default group can view and change theuser’s own profile and other information, activities, and accounts and access.

Planning 7

All IBM Tivoli Identity Manager users that do not explicitly belong to a group areautomatically granted the base level of permissions and granted access to the baseset of views, as described in Table 4.

Table 4. End-user permissions and access

Default tasks in view Default access control items

v Change your passwords, and specifyinformation for your forgotten passwordquestions.

v View your personal profile.

v View and request your accounts. Youcannot change, delete, suspend, or restoreyour own account.

v View and request your access. You cannotchange, delete, suspend, or restore youraccess.

v View your activities.

v Search and change your password.

v Search, add and change your accountpassword.

v View basic data about a service, such asservice name and description.

Scope of the Auditor group:

The scope of activities for members of the Auditor group is primarily to requestreports and search for other information.

An auditor can run all reports and also search for a limited amount of informationother than reports, such as roles, as described in Table 5.

Table 5. Default scope of Auditor group


v On the self-service console:

– Change your passwords, and specifyinformation for your forgottenpassword questions.

– View your personal profile.

– View and request your accounts. Youcannot change, delete, suspend, orrestore your own account.

– View and request your access. Youcannot change, delete, suspend, orrestore your access.

– View your activities.

v On the administrative console:

For all users:

– Run any report in all major reportgroups, including requests, users andaccounts, audit and security, services,and custom reports.

– View all requests, pending requests byuser or service, all requests by user orservice.

v Self-care

– Search and change your password.

– Search, add and change your accountpassword.

– View basic data about a service, suchas service name and description.

v Administrative

For all users:

– Search for account, dynamic role,location, role, organizational unit,person, and provisioning policy.

– Run reports of all kinds, ranging fromaccount to user requests.

Scope of the Help Desk Assistant group:

8 Planning

The scope of activities for members of the Help Desk Assistant group is primarilyto control the passwords, profiles, and accounts of other users.

These tasks might not be available if the person form is customized to excludesome of the attributes for which the help desk assistant has permission to read orwrite. Additionally, help desk assistants can restore accounts, as well as viewothers’ requests and both manage and delegate to-do lists, as described in Table 6.

Table 6. Default scope of Help Desk Assistant group


v Self-service console



– View, request, delete your accounts.You cannot change, suspend, or restoreyour own account.

– View, request, delete your access. Youcannot change, suspend, or restore youraccess.


– Manage delegation schedules.

v Administrative console

For all users:

– Create, change, delete, suspend, restore,and transfer users.

– Change passwords for other users anddelegate their activities.

– Create, change, delete, suspend, andrestore accounts.

– Request and delete access.

– View pending requests by user and allrequests by user.

– View activities for the Help DeskAssistant, and for other users.


v Self-care




v Administrative

For all users:

– Perform all operations with allpermissions on none-administrativeaccounts.

– Search business partner organizations,non-administrative groups, locations,roles, organizational units.

– Perform all operations with allpermissions on persons and businesspartner persons.

– Delegate to-do lists.

Scope of the Manager group:

The scope of activities for members of the Manager group is primarily to managethe accounts, profiles, and passwords of their direct subordinates.

These tasks might be unavailable if the person form is customized to exclude someof the attributes for which the manager has permission to read or write. Managerscan manage and delegate activities on their to-do lists, as described in Table 7 onpage 10.

Planning 9

Table 7. Default scope of Manager group





– View, request, and delete youraccounts. You cannot change, suspend,or restore your own account.

– View, request, and delete your access.You cannot change, suspend, or restoreyour access.




For supervised users:

– Suspend and restore users.

– Change user passwords and delegateuser activities.

– Request, suspend, restore, and deleteuser accounts.

– Request and delete user access.

– View pending requests by a user or allrequests by a user.

– View the activities and managedelegation schedules.

v Self-care




v Administrative

For supervised users:

– Run reports for:

Account Operations

Account Operations Performed byan Individual

Accounts/Access PendingRecertification

Approvals and Rejections

Individual Access

Individual Accounts

Operation

Pending Approvals

Recertification Change History

Recertification Policies

Rejected

User

– Delegate activities to users.

Scope of the Service Owner group:

The scope of activities for members of the Service Owner group is to manage aservice, including the user accounts and requests for that service.

Additionally, on services they own, service owners can view requests that otherusers make, such as authorizing an account, unless the person form is customizedto exclude some of the attributes for which the service owner has permission toread or write. A service owner can manage and delegate activities on their to-dolists, as described in Table 8 on page 11.

10 Planning

Table 8. Default scope of Service Owner group





– View, request, delete your accounts.You cannot change, suspend, or restoreyour own account.

– View, request, delete your access. Youcannot change, suspend, or restore youraccess.




For the owned service:

– Create, change, and delete a service.

– Manage groups on a service, includingmembership, access, and recertificationstatus. A service owner cannot add agroup.

– Manage accounts on a service,including requesting, changing,deleting, suspending, restoring,assigning, and making orphanaccounts. Additionally, manage accountdefaults, recertification status, andreconciliation.

– Manage all policies on a service.

– Design workflows for account andaccess requests.

– Request reports for users and accounts,services, and custom reports.

– View all pending requests by serviceand all requests by service.

– View activities for the Service Owner.


v Self-care




v Administrative

For the owned service:

– Add a service owner group.

– Run reports for access, individualaccess, orphan accounts, dormantaccounts, pending recertification,recertification history, andrecertification policies.

– Add and modify accounts and accountdefaults.

– Search accounts, account defaults,admin domains, business partnerorganizations, organization units, andalso groups, users, locations, persons,and service owners.

– Use all permissions and operations onall policies.

– Use all permissions and operations onworkflows.

Access control item management issuesManaging access control items requires your attention to the need to createcustomized access control items, and to recognize and solve potential conflictsbetween access control items that grant similar rights.

Customized access control itemsAs an administrator, you can create customized access control items. For example,an access control item might limit an operation for members of a customizedService Owner group.

Planning 11

Coordination between access control itemsYou need to coordinate the outcome when multiple access control items apply tothe same operation or attribute. It is possible that a user could be grantedpermissions by one access control item that are denied by another access controlitem.

In cases of multiple group memberships, a user’s access is enabled based on thewidest privilege granted to any of the groups in which the user is a member.However, the user’s access is disabled if it is explicitly denied to any of the groupsof which the user is a member.

When two or more access control items conflict, the following rules apply:v An explicit denial (using a Deny selection) by one access control item overrides

an explicit grant by other access control items.v An explicit grant by one access control item overrides an implied denial (using a

None selection) by other access control items.

Use the Deny selection sparingly, because an explicit denial overrides all otherchoices. Consider using the None selection instead of the Deny selection.

For a given attribute, the permission for a write operation takes precedence overthe permission for a read operation. For example, if you explicitly deny readpermission and explicitly grant write permission, you are able to see the attributeon the form, because the write permission takes precedence over the readpermission.

Generally, if a user is granted permission to view or modify an attribute, the usercan also see the attribute on the user interface even if read permission is denied.For example, if an access control item grants permission to define an access group,a member of the access control item can also view the access group list, regardlessof whether the operation to view group members is granted or denied.

An example focus problem and solutionA problem in focusing an access control item can occur when you create acustomized access item for an account object class.

For example, you might intend to prevent Read and Write operations for theDescription attribute of an account object class. You might specify a permissionvalue of None for both operations and select the membership of the access controlitem as the owner of the service on which the account resides. Testing the newaccess control item, you then log on as the service owner and begin to request anaccount for another user. You discover that you are still able to both read and writethe account description field.

There are two causes:v The membership specification of the new access control item applies to accounts

that exist. In this case, the membership is for the owner of the service on whichan existing account resides. However, the access control item does not preventRead and Write operations during the account creation process, before theaccount exists.

v As service owner, you belong to the service owner group, has an access controlitem named Default ACI for Account: Grant All to Supervisor/DomainAdmin/Sponsor/Service Owner/Access Owner.In your customized access control item, you specified a permission value ofNone for both operations. However, the default access control item specifies a

12 Planning

permission value of Grant, which takes precedence over a value of None in anyother access control item that applies to the operation.

You might make these changes to your customized access control item:v Change the permission value to Deny for the Read and Write operations. The

use of Deny by one access control item overrides an explicit Grant by otheraccess control items. Use the Deny selection sparingly, because an explicit denialoverrides all other choices.

v Change the membership of the customized access control item to include theservice owner group. The change ensures that the access control item appliesduring account creation.

Entity types used by access control itemsAccess control items focus on target entity types.

IBM Tivoli Identity Manager provides default access control items that target aprotection category. You can also assign a specific object class, such as theerPosixLinuxAccount object class, to an access control item.

Access control items focus on an entity such as an account, organization, or role.Some access control items require the selection of an entity subclass. An accesscontrol item can focus on these categories of entity types:

AccountRepresents a user’s access to a managed resource.

Note: Install the service profile for the managed resource on which thedesired accounts reside before creating an access control item for theaccount object class.

Account Default TemplateProvides default values for account attributes when requesting an accounton a service.

Admin DomainIdentifies a subsidiary part of an organization as a separate entity with itsown policies, services, and access control items, including an administratorwhose actions and views are restricted to that domain.

Business Partner OrganizationIdentifies a business partner organization, which is typically a companyoutside your organization that has an affiliation, such as a supplier,customer, or contractor.

Business Partner PersonRepresents an employee of an outside entity with which your organizationis affiliated, such as a supplier or customer.

Dynamic Organizational RoleSelects users based on the attributes in an LDAP filter, such as the title of auser. When a user is added to the system and the LDAP filter parametersare met, the user is automatically added to the dynamic role.

ITIM GroupA collection of users with accounts on the IBM Tivoli Identity Managerservice.

Service GroupA collection of users with user accounts on a specific service, such as anaccounting application.

Planning 13

LocationA container that is different geographically, but contained within anorganization entity.

Organizational UnitIdentifies a subsidiary part of an organization, such as a division ordepartment. An organization unit can be subordinate to any othercontainer, such as organization, organizational unit, location, and businesspartner organization.

PersonA person whose identity record is managed as an account by IBM TivoliIdentity Manager.

Identity PolicyDefine who has access based on an identity policy.

Password PolicyDefine who has access based on a password policy.

Provisioning PolicyDefine who has access based on a provisioning policy.

Recertification PolicyDefine who has access based on a recertification policy.

Service Selection PolicyDefine who has access based on a service selection policy.

ReportReport access control items define which groups are allowed to run aspecific type of report. For example, the service owner group might haveaccess to run the Orphan Accounts Report and the auditor group mighthave access to run the Recertification Change History Report.

ServiceIdentifies a managed resource, such as the Windows NT® Service, as wellas IBM Tivoli Identity Manager itself.

Static Organizational RoleA subset of one or more privileges that can be assigned to users. Forexample, the ITIM Administrators role is a predefined role.

If a role is a member of another organizational role, then that role memberinherits the permissions of the organizational role. Therefore, all membersof the organizational role and its role members have the same set ofprivileges.

Workflow DesignDefines who can create or modify account and access entitlementworkflows.

Access entitlements and access control itemsAccess control items defined for Service, Service Group and Account control auser’s access privilege for access configuration and user access management foraccess based on service group.

Access control items defined for role, dynamic role, and Person control the accessprivilege for access management and user access management for access based onan organizational role.

14 Planning

IBM Tivoli Identity Manager provides default access control items that targetaccess entitlements, as described in Table 9.

Table 9. Access entitlements and access control items

Who is permitted

Default access control itemsrelated to accessmanagement Effect

All users Service group - read allaccess attributes

Static role - search andmodify

Dynamic role - search

Person - modify and errolesattribute read/write for self

Account - search, add, viewand remove group memberfor self

Allow users to request thatnew access be authorizedand to view and removetheir own access.

Manager or supervisor or theaccount owner

Service group - search andread all access attributes



Person - modify and errolesattribute read/write forsubordinates

Account - search, add, viewand remove group memberfor subordinates

Allow a manager to view,request, or remove asubordinate’s access.

Help desk assistant Service group - search andread all access attributes



Person - modify and errolesattribute read/write for all

Account - search, add, viewand remove group memberfor all

Allow all help desk users toview, request, or removeaccess for all users in theorganization.

Service owner or accessowner of the service onwhich the account resides

Service group - all accesscontrol item operations

Account - all access controlitem operations

Allow service owners oraccess owners to search agroup, define access, recertifyaccess, and manage accountsand group members for aservice or defined access thatthey own on the service.

Planning 15

Table 9. Access entitlements and access control items (continued)

Who is permitted

Default access control itemsrelated to accessmanagement Effect

Sponsor of the businesspartner organization inwhich the account resides

Service group - search orread all access attributes

Account - search, and add,view, or remove groupmember

Allow a sponsor to view,request, or remove asubordinate’s access.

Auditor group Service group - search

Account - search, read allaccess attributes

Allows members of theauditor group to view accessreports.

Service owner or auditorgroup

Reports (access) - runoperation

Allows members of theservice owner or auditorgroups to view the accessreport.

Auditor, manager, or serviceowner groups

Reports (individual, access)-run operation

Allows members of thesegroups to view theindividual access report.

Recertification policies and access control itemsRecertification policies can also be targets of access control items.

IBM Tivoli Identity Manager provides default access control items that targetrecertification policies, as described in Table 10.

Table 10. Recertification policies and access control items

Who is permittedTarget object and accesscontrol item Effect

Service owner group Recertification policy - add,modify, remove, or search

Allow service owners tomanage recertificationpolicies.

Auditor or manager group Recertification policy - search Allows members of theauditor group or managergroup to search or viewrecertification policies.

Auditor, manager, or serviceowner groups

Reports (recertificationpending, history, andpolicies) -run operation

Allows members of thesegroups to view these reports.

Role planningManaging roles requires understanding the application of access control and accessprovisioning models in a customer deployment, and subsequently specifying staticor dynamic role members, and determining the appropriate scope of a role in anorganization tree.

Access control modelsThere are several commonly found access control models in a centralized identitymanagement solution. The access control model that an organization uses dependson certain factors, such as externally mandated policies, the maturity of existing

16 Planning

identity management processes, the range of identity management target systems,future requirements, the number of users managed, risk assessment statistics, andreturn on investment statistics.

In IBM Tivoli Identity Manager, organizational roles can be used to support thefollowing types of access control models:

Role-Based Access Control (RBAC)This model grants access privileges to users based on the work that theydo within an organization. The model allows an administrator to assign auser to single or multiple roles according to their work assignments. Eachrole enables access to specific resources.

Discretionary Access Control (DAC)This model enables the owner of a resource to decide whether to allow aspecific person access to the owned resource. This system is common indistributed environments that have evolved from smaller operations intolarger ones.

Mandatory Access Control (MAC)This model enables grouping or marking resources according to asensitivity model. This model is most commonly found in military orgovernment environments. An example of this model is the marking ofUnclassified, Restricted, Confidential, Secret, and Top Secret resources. Theprivileges that a user is granted to view certain resources depends on theclearance level of the user.

Access provisioning modelsIBM Tivoli Identity Manager provides role-based and request-based accessprovisioning models.

Role-basedAccess to managed services are provisioned automatically based on theuser’s roles in the organization. To some degree, role-based provisioningcan be used to support a role-based access control model when accesscontrol is not centrally managed by a common access control system. Theautomation between the role and accounts and groups on the targetresource, and strict enforcement of role relationships, ensures that access tothe IT resource is based on the user’s role.

Request-basedAccess entitlements are authorized to a user based on the user’s roles inthe organization, so that the user or other managers or administrator canrequest the account or access.

Request-based provisioning is often used to support Discretionary Access Control(DAC) and Mandatory Access Control (MAC) access control with a combination ofappropriate approval processes. Sometimes there might be mixed usage of the twomodels for different sets of users in the organization, or for different sets of targetservices.

Organizational roles and access provisioningA user role, also termed a business role or positional role, is used to represent agroup of users with a particular meaning in a business model, such as aclassification of users who share a business function.

Planning 17

User roles can be modeled with an organizational role in IBM Tivoli IdentityManager and used to support role-based provisioning. A user role can be mappedto a set of access entitlements in the provisioning policy so that the access to ITresources is automatically provisioned for the users that belong to the role.

User roles are often modeled to help with user management for the business, anduser roles can also be used to support role-based access control and role-basedprovisioning. Access to IT resources might be managed by the following systems:

Central access control systemA role-based access control model grants access to resources based on auser role, such as the user’s job title or work responsibility.

Distributed system for a specific resourceA role-based provisioning model automates the access entitlementprovisioning process for a specific managed resource, based on the roles towhich the user belongs.

Consider the following items when designing provisioning policies:v The target services to managev The number of groups on each servicev The number of user roles in the organizationv The pattern of user roles and access entitlement mappings to the target services

An access entitlement can be simply mapped to an account on a service or tospecific group members on a service. A provisioning policy allows a user role tomap to multiple entitlements for different services, and it allows multiple roles tohave the same set of access entitlements. On the other hand, it is also possible tohave multiple provisioning policies for the same role, each granting a set ofaccesses for the role.

An organizational role in Tivoli Identity Manager can also be used to representaccess to IT resources. The access can be mapped to one or multiple services thatrepresent aggregated access to the resources. The accesses are defined by using aTivoli Identity Manager provisioning policy with automatic entitlement andmandatory entitlement parameters.

This type of organizational role can be directly exposed to the user for accessrequests, and can be categorized based on its access type, such as access to anapplication or a shared folder.

This type of organizational role provides request-based provisioning by enablingrequests to aggregated accesses. By giving the proper business-oriented name anddescription to the access, and by setting up accesses in a provisioning policy andspecifying the appropriate role approval process, you can build a provisioningmechanism to support the access control models that were described earlier in thisinformation.

If the role is a child role of another organizational role, which then becomes aparent role, then that child role inherits the permissions of the parent role. Inaddition, if a role is a child role of another organizational role in a provisioningpolicy, then that child role also inherits the permissions of provisioning policy.

For more information about how to design these access control systems, see theIBM Redbooks® that describe design activities for Tivoli Identity Manager.

18 Planning

Static and dynamic rolesIBM Tivoli Identity Manager provides static and dynamic roles.

In static organizational roles, assigning a person to a static role is a manualprocess.

In the case of a dynamic role, the scope of access can be to an organizational unitonly, or to the organizational unit and its subunits. Dynamic organizational rolesuse valid LDAP filters to set a user’s membership in a specific role. For example, adynamic role might use an LDAP filter to provide access to specific resources tousers who are members of an auditing department named audit123. For example,type:(departmentnumber=audit123)

Dynamic organizational roles are evaluated at the following times:v When a new user is created in the Tivoli Identity Manager systemv When a user’s information, such as title or department membership, changesv When a new dynamic organizational role is created

Roles in the organization treeYou can use roles to model a job title or responsibility, and you can use roles togrant access to accounts and attributes.

Both a static role and a dynamic role can be associated with a business unit in theorganization tree, which can be used to support delegated administration for a roleor role assignment. An access control item can specify which user is allowed tocreate, modify, or delete a role, based on the association of the role in theorganization tree.v A static role can be located anywhere in the tree. Any user in the same

organization can be manually attached to the role.For a static role, an access control item can specify who is allowed to add orremove users from the role-based association in the organization tree of the roleand user.

v A dynamic role defines membership based on an LDAP filter and has a scoperelative to its position in the tree. Placement of dynamic roles within anorganization tree can have performance implications. For more information, referto the IBM Tivoli Identity Manager Performance and Tuning Guide.The scope of a dynamic role can be one of the following:

Single Applies to users in the local business unit

SubtreeApplies to the local business unit and all sub-business units

For example, suppose that an organization has a depth of containers for the userpopulation, similar to Figure 2 on page 20.

Planning 19

Suppose that you configure dynamic roles similar to this list:– role_A for DivisionA– role_A1 for department A1– role_A1_1 for branch 1 in department A1If each of these dynamic roles has a scope of subtree and an LDAP filter such as(objectclass=*), then a user located in ou=A1branch1 receives all three roles:role_A, role_A1, and role_A1_1.To specify that a discrete dynamic role applies to users based on their location inthe tree, you might need to place the users in the leaf nodes (containers), makethe LDAP filter very specific, or specify the role scope as single.

Planning an organization treePlanning an organization tree has multiple considerations.

For example, planning an organization tree includes these activities:v Obtaining agreement on the primary and secondary requirements that a

structure must satisfy.v Clarifying the degrees and levels of delegated administration for subsets of

services or users, and then specifying admin domains that accomplish thesegoals.

v Using automated identity feeds to load identity records.v Determining user access privileges with different degrees of scope within the

branches of an organization.v For geographically-dispersed organizations, enabling a flow of changing

administrative access to the system for a given region, or time interval.v Determining effective change control of policies, roles, groups, and other security

functions that IBM Tivoli Identity Manager provides.v Determining the scope of influence within an organization tree for IBM Tivoli

Identity Manager policies and workflow participants such as supervisors, andadministrators.

v Enabling ease in migration from pilot to production-level structures.

Organization tree modelsAn organization model can use simple or very complex branching.

For example, within a given branch in an organization tree, a structure of servicesand users might provide:

MyOrganization

All Services

DivisionA DivisionB

DeptA1

A1branch1 A1branch2

DeptA2

Figure 2. Example roles

20 Planning

v All-in-one organizationBoth the user and the services reside within a single organization. An all-in-onemodel for all services and users has limited use because, although simple toadminister, the model is not scalable to a large user population.

v Separate branches for services and for usersSeparate branches might provide a services branch and a user branch in anorganization. Issues can arise in administration and deployment for differentdepths of subordinate objects in each branch. Designing the structure mustconsider the difficulty in moving services and policies within a tree, compared tothe relative ease in moving users.For most objects, once the object is created within an organizational container, itmust be deleted and created again to put the object into a differentorganizational container. However existing users can be moved to a differentbusiness unit by use of a transfer.For example, an organization might manage services as one branch in a resourcetree, and employees in another branch, in a structure similar to Figure 3.

v Exact replication of an entire hierarchy of a continuously changing businessAlthough not recommended, you might attempt to maintain an ongoing, exacttree that represents your business organization. Changes that occur in thehierarchy and membership of the persons business itself then require exactsynchronization of the users within an electronic organization tree.

Model exampleAn organization might need an extended structure to manage its services andemployees.

For example, an organization might require a structure similar to Figure 4 on page22.

MyOrganization

All Services Users

Figure 3. Example configuration

Planning 21

Advantages in this example include:v The high-level split of services from people separates identity management from

management of the solution.To implement the structure, you would configure admin domains to providemanagement of objects.

v The user container structure is based on one or more user attributes, ascompared to alternative structures for a reporting or other line of businesshierarchy, in a structure similar to Figure 5.

In this example:v The user branch is a simple structure based on a common piece of data, such as

the surname (family name). This model is easy to deploy, and requires very littleplacement rule coding for the identity feed.The branch structure is largely based on the information available in the identityfeed and the number of users in each container, requiring analysis on theidentity data before confirming the structure.

v The services branch contains all services, policies, and other objects along withtheir access control items. The structure depends on the requirements formanagement and ownership of the services, and other considerations.

MyOrganization

All Services

Permanentemployees

PermanentA-K

ContractorA-ZPermanent

L-Z

Contractors

Figure 4. Example organization chart

MyOrganization

All Services

Permanentemployees

PermanentA-K

ContractorA-ZPermanent

L-Z

Contractors

Person andAccount ACIs

PoliciesService ACIs

Other object ACIs

Figure 5. Example organization chart

22 Planning

When pilot tests are complete, deploying a more complex structure might keep theservice branch as it is, and build the new user structure. You then move the usersinto the new structure.

There are many alternatives other than this example. For an organization withcentralized management, you might create a branch that contains services, and aseparate branch or branches that contain users, each with its own delegatedadministration. For organizations with distributed management, you might create acontainer that has both services and people.

For additional information on organization design for IBM Tivoli Identity Manager,refer to Redpapers or Redbooks that might be published for this product by theIBM International Technical Support Organization, and to IBM Global BusinessServices or another suitably-qualified project management consultant.

Scope of governing entities in the organization treeMost IBM Tivoli Identity Manager policies allow you to specify the scope of thegoverning services in the organization tree based on the policy’s association withthe business unit.

A dynamic role supports the scope of governing users based on its associationwith the organization tree. An access control item supports the scope for theprotecting object types, based on its association with the organization tree.

The scope of policies, roles, and workflows differ in their effects in an organizationhierarchy, as summarized in Table 11.

Table 11. Scope and inheritance in a tree

Entity Type Scope of Governing Entity

Identity policy Services associated with the same business unit or in thesub tree below.

Password policy Services associated with the same business unit or in thesub tree below.

Provisioning policy Services associated with the same business unit or in thesub tree below.

Service selection policy Provisioning policies associated with the same businessunit or in the sub tree below.

Static role Users in the entire organization to which the role belongs.

Dynamic role Users associated with the same business unit or in the subtree below.

Workflow Service or Access in the entire organization.

Access control item Objects (based on the protected object type) associatedwith the business unit or in the sub tree below.

Provisioning policiesA provisioning policy grants entitlement to accounts on managed services for set ofroles.

A provisioning policy will govern roles and users within the entire organizationregardless of the policy’s association with the business unit in the organizationtree; but it only governs services that are associated the same business unit or subtree of the business unit that the policy is associated with. The provisioning policymust be at the same level or higher than the related service.

Planning 23

A role referenced in the provisioning policy can be anywhere in the tree of theorganization. Any user can be manually attached to the role.

Service selection policiesService selection policies extend the ability of provisioning policies by provisioningaccounts based on user attributes.

Using JavaScript™, service selection policies determine a user attribute, such asgeographic location, to select a service, such as a local Windows® service in ageographically dispersed business.

The scope of a service selection policy determines which provisioning policies areaffected:v Single

Only provisioning policies at the same level in the organization tree canreference the service selection policy.

v Subtree scopeOnly provisioning policies at or below the same level in the organization treecan reference the service selection policy.

Identity and password policiesAn identity policy determines the user ID for account creation. A password policysets the password strength rules.

Both identity and password policies should be placed at the same level or higherthan the services to which they are applied, and the scope can be set as single levelor subtree. Identity and password policies can cover all services, a specific serviceprofile, or a set of services within the scope.

WorkflowsA workflow is a set of steps or activities that define a business process. Forexample, you can use workflows to customize account provisioning and lifecyclemanagement, such as adding, removing, and modifying users and accounts in IBMTivoli Identity Manager.

There is no inheritance relationship between a workflow and users or policies in anorganization tree. A workflow does not need to be at or above a level in anorganization tree. There is no inheritance of workflows to users; There is noplacement relationship between workflows and provisioning policies.

Workflow participants:

A key component of approval workflow nodes is the participant and escalationparticipant, which is one or more signature authorities that must approve or rejectthe request.

The participant can be an individual or a group of individuals, including therequestee, the person for whom an action is performed, the requestor, whoperforms an action, the service owner, or the system administrator.

Some participant types are organization-related participants:v Sponsor, for a workflow in which a valid requestee is specified.

You can specify a sponsor for each business partner person or business partnerorganization. A workflow determines the sponsor that is appropriate to the

24 Planning

requestee, based on a BPPerson object or BPOrg object. In the tree, the Sponsorthat is selected is the closest to the requestee BPPerson.

v Supervisor, for a workflow in which a valid requestee is specified.You can specify a supervisor for users, organization units, and locations. Aworkflow determines the supervisor that is appropriate to the requestee, basedon the Person object, or from the closest location or organization unit object thathas a supervisor. In the tree, the Supervisor that is selected is the closest to therequestee person.

v Domain administrator, for a workflow in which the service subject or requesteeis specified. If the service is not specified, it is based on the admin domain thatis closest to the requestee.You can specify an administrator for an admin domain. A workflow determinesthe administrator based on the admin domain that has an administrator and isclosest to the service.

Workflows and the organization tree:

Workflows can use one of the dynamic participant types that are determined atruntime, or they can explicitly map an object instance, such as a specific user, as aparticipant.

The workflow participant in a business unit is termed Supervisor. In a Personprofile, and also in an access control item, the workflow participant is termedManager. For example, a Supervisor participant is based on the Managerrelationship of a Person or Supervisor relationship of a business unit.

Participant resolution is based on a relationship to the entity, which hasdependency on the organization tree:v Manager (approver) is defined on a Person object

In this case, generic workflows can apply to all parts of the organization tree.For example, approval for a new account request might go to the line managerfirst, and then to the owner of the service that has the account.

v Manager (approver) is defined on an organization unit, such as a teamIn this case, the leaf nodes of the organization tree need to be the teams towhich each user belongs, and their line manager is specified as theirsupervisor/sponsor.

Access control itemsAn access control item only applies to entities of protected category within itsbranch or, specified with subtree scope, in lower branches of an organization tree.

An access control item applies to entities and processes only within its branch or,specified with subtree scope, in lower branches of an organization tree. Most of theaccess control items are defined at the Organization level. There are additionalconsiderations, such as:v Creating access control item at a specific business unit in the Organization to

grant operations and permissions for objects within that branch.v For business unit object such as a business partner organization, an access

control item has to be originated one level higher, with a target entity type ofbusiness partner organization, to enable search functionality.

Customization and bulk loading of identity dataConfiguring organization trees must also consider requirements to providecustomization and bulk loading of identity data.

Planning 25

Customization using JavaScript APIs:

The organization tree may drive some requirements for customization that can beused to support the customer-specific business processes.

For example, to dynamically assign approvers based on the association of the userto the organization tree, JavaScript APIs are often used to look up or search forvarious type of business units in the organization tree based on the attributes ofthe user.

Bulk loading:

Although a small user population, such as tens or a few hundreds of users, mightpermit manual loading of identity data, most projects require a bulk load process.Manual loading is likely to also require manual refreshing of identity data, addingsignificant administrative overhead to the project.

The IBM Tivoli Identity Manager data load mechanism can include JavaScript todefine where each new user is placed in the tree. If you do not include aplacement rule, all users are placed into a default organization, and you must latermove each user into the correct organization container.

To bulk load users into their correct organization container, you will need to defineplacement rule to place the user into the proper organization container. You cancode JavaScript to use some user attribute in identity feed for incoming Personobject data, to look up the Organization container in the placement rule definition.

Workflow planningTo plan workflows for your business needs, you need to understand the behaviorof the initially-installed workflows.

Planning also includes that you analyze the business requirements and policies thatare related to account and access provisioning. You will need a design that meetsthese requirements. Your implementation of the design will create additionaloperations, customize initially-installed operations, and define appropriate accountand access request workflows to support the approval process.

Operation workflowsOperation workflows define the business processes for managing the account, user,and business partner user entities.

When an administrator adds, removes, or modifies an entity using the IBM TivoliIdentity Manager graphical user interface or the APIs, the operation workflows areused to complete the request. To implement your specific business processes, youcan customize operation workflows by modifying both the flow and the specificactivities. You can also extend Tivoli Identity Manager capabilities to call newoperations by creating new operations and by using the APIs, life cycle rules, andoperation workflow activities.

Operation workflows support both input and output parameters.

Operation levelsOperation workflows are defined at global and also at lower levels in the system.

26 Planning

The available operations depend on which operation level is selected. ClickConfigure System > Manage Operations to access these operation levels in theIBM Tivoli Identity Manager console.

GlobalApplies to all entities and entity types. A global operation is always a staticoperation that does not require a target entity.

Entity typeApplies to all entities of that specific type, such as an Account or Personentity. For static operations, an entity type defines the namespace of theoperation; for a nonstatic operation, an entity type defines the type of thetarget entity. An operation at the entity type level does not overwrite anoperation at the global level.

Entity Overrides the operations that are defined at the entity type level.

Static and nonstatic operationsLifecycle operations are either static or nonstatic. Static operations are applied toan entity or entity type; nonstatic operations are applied to a specific instance of anentity.

Static operationA static operation is an operation defined for an entity or an entity typethat is not invoked on a particular instance of the entity. All inputparameters of static operations are explicitly defined.

In static operations, the target of the operation is passed as inputparameters, or is resolved as part of the operation workflow. To ensure thatthe operation workflow completes successfully, you must pass theappropriate information about the target to the operation.

For example, when the add account operation is invoked, the accountprofile must be passed to the add account operation to begin with. Thisprofile information helps distinguish between the entity types (Accountand Person), and entity operations and entity type operations. The target ofthe operation does not have to be an entity that IBM Tivoli IdentityManager manages, because the target of the operation will not be used toresolve operation definitions.

If you are adding an existing operation to a workflow, you must map therelevant data items to all of the input parameters of the new operation.Mapping consists of matching relevant data items to input parametersbetween two or more operations. For example, if you change the workflowfor a modify Person operation to transfer a user when changes are made totheir bu attribute, you will create a relevant data item to contain the user’snew container. You will then map this to the input of an extensionworkflow node of the transfer Person operation.

The static operations are:v add (Account, Person)v modify (Account)v selfRegister (Person)

Nonstatic operationA nonstatic operation is an operation defined for an entity or entity typethat has to be invoked on a specific instance of an entity that is currentlymanaged by IBM Tivoli Identity Manager to ensure that the query and theoperation workflow succeed.

Planning 27

The target of a nonstatic operation is passed into the operation as entitycontext information. The entity (Account or Person) that the workflowapplies to is passed implicitly to the workflow, and it is always mapped toa relevant data named Entity, rather than an input parameter. The target ofthe operation, the Entity object, must exist in IBM Tivoli Identity Manager.An entity (Account, Person, Business Partner Person) is added to IBMTivoli Identity Manager using the appropriate add operation.

All nonstatic operations have a relevant data item with an ID of Entity, andthis relevant data item represents the target of the operation. Like all otherrelevant data, this relevant data item can be used to provide inputparameters to activities and can be accessed using JavaScript scripting tosupport additional customization of the operation workflow.

The nonstatic operations are:v delete (Account, Person)v modify (Person)v suspend (Account, Person)v restore (Account, Person)v transfer (Person)v changePassword (Account)

System-defined operationsIBM Tivoli Identity Manager includes a set of system-defined operations thatimplement the features of the system.

The system-defined operations are specific to the entity types. Although you cancustomize these operations, you cannot change the input parameter definitions, thetype of operation (static or non-static), or the name of the operation. ClickConfigure System → Manage Operations to access these operations in the TivoliIdentity Manager console.

If you directly customize a system operation of an entity type, you cannot delete itand then later restore it back to the default operation. Deletion of a system-definedoperation for an entity type is not allowed. You must manually remove thecustomization.

Operations defined for entities override operations that are defined for entitytypes. That is, if an operation with the same name exists for both an entity and anentity type, the entity operation is the operation that is invoked by the operationworkflow. Because system-defined operations implement the base businessprocesses for Tivoli Identity Manager, exercise caution when customizing theseworkflows.

For example, if you have specific business process requirements, you should createa user-defined operation by overriding the system-defined entity type operations.The system-defined delete operation for the Account entity type deprovisions theaccount and permanently removes the user data from the remote system. Toprevent the loss of that user data on AIX® systems, you can create a deleteoperation for AIX accounts that sends a request to the service owner of the AIXsystems to ask them to specify whether to suspend the account or go ahead anddeprovision the account. Because this user-defined entity operation is specific toAIX accounts, all other accounts are still managed by the system-defined entitytype operation, which deprovisions the account and removes the user data fromthe remote system.

28 Planning

When you customize an entity type operation for a specific entity, a copy of thesystem-defined entity type operation is created such that you do not change thesystem-defined entity type operation. If you want to return to the system-definedentity type definition, delete the entity operation that you created.

Tivoli Identity Manager provides the following system-defined entity types:

GlobalSpecifies all entity types below (Account, Business Partner Person, Person).

AccountSpecifies all account types, such as Tivoli Identity Manager user accounts,Linux® accounts, or Tivoli Identity Manager accounts.

Business Partner PersonSpecifies all business partner user types, including the default businesspartner entity and any custom business partner entities.

PersonSpecifies all person types, including the default Person entity and anycustom Person entities.

For the Person and Business Partner Person entity types, Tivoli Identity Managerprovides the following system-defined operations:

Table 12. Person and Business Partner Person entity type operations

Operation Description Type

add Creates a user in TivoliIdentity Manager andenforces the policy on thenew user

Static

delete Deletes a user from IdentityManager

Nonstatic

modify Modifies a user’s attributesand enforces policy on theupdated user

Nonstatic

restore Restores an inactive user Nonstatic

selfRegister Creates a user in IdentityManager and enforces policyon the new user

Static

suspend Suspends an active user Nonstatic

transfer Transfers a user from onebusiness unit to another, thenenforces policy when thetransfer is complete

Nonstatic

For the account entity type, Tivoli Identity Manager provides the followingsystem-defined operations:

Table 13. Account entity type operations


add Creates a new account Static

changePassword Changes the password for anaccount

Nonstatic

delete Deprovisions an account. Nonstatic

Planning 29

Table 13. Account entity type operations (continued)


modify Modifies an account. Static

restore Restores an inactive account Nonstatic

suspend Suspends an active account Nonstatic

User-defined operationsUser-defined operations include new operations that you create.

These operations can be either static or nonstatic, and they can be defined at anyone of the following operation levels: Global, Entity Type, and Entity. ClickConfigure System → Manage Operations to access these operations in the IBMTivoli Identity Manager console.

The user-defined operations are not invoked directly from the Tivoli IdentityManager system. Typically, these user-defined operations are invoked as anoperation activity in system-defined operations to customize the default TivoliIdentity Manager behavior. User-defined operations can also be invoked using lifecycle application APIs directly in custom-built Tivoli Identity Managerapplications.

Operation workflow parametersOperation workflows possess a set of input and output parameters. Theseparameters depend upon the operation that you select. They can also be modified.

Input and output parameters for operation workflows can be modified as follows:v For system-defined operations, you can modify output parameters but not input

parameters.v For user-defined operations, you can modify both input and output parameters.v You can map existing output parameters to the relevant data and to the output

parameter relevant data identifiers.v You can add, modify, or delete output parameters. After you add an output

parameter, you must map it to relevant data. The relevant data can be modifiedor deleted, provided that it is not referenced by any input or output parameters,and new relevant data can be added.

User account and access request workflowsAccount and access request workflows are invoked during account and accessprovisioning.

You typically use account and access request workflows to define approvalworkflows for account and access provisioning. Click Design Workflows in theIBM Tivoli Identity Manager console to work on these workflows. These workflowdesign features are available when you select the advanced method to designworkflow activities.

Account request workflowsAccount request workflows provide a decision-based process to determine if theentitlement provided by a provisioning policy should be granted.

The entitlement provided by a provisioning policy specifies the account requestworkflow that applies to the set of users in the provisioning policy membership. If

30 Planning

there are multiple provisioning policies that apply to the same user for the sameservice target, and there are different account request workflows in eachprovisioning policy, the account request workflow that is invoked for the user isdetermined based on the priority of the provisioning policy.

If a provisioning policy has no associated workflow, and the policy grants anaccount entitlement, the operations that are related to the request, run immediately.For example, an operation might add an account.

However, if a provisioning policy has an associated workflow, that workflow runsbefore the policy grants the entitlement. If the workflow returns a result ofapproved, the policy grants the entitlement. If the workflow has a result ofrejected, the entitlement is not granted. For example, a workflow might require amanager’s approval. Until the approval is submitted and the workflow completes,the account is not provisioned.

When you design a workflow, consider the intent of the provisioning policy andthe purpose of the entitlement itself. For example, a provisioning policy intendedto automatically provision an intranet ID for every new person in an organizationdoes not need an associated workflow that contains an approval activity. Anapproval request that might be rejected is in conflict with the intent to assign anintranet account to every new employee.

Workflows for an account contain types of information that are pertinent to theworkflow: input parameters and output parameters. Input and output parametersare mapped to relevant data defined in the entitlement workflow. The mapping ofinput parameters to the relevant data is pre-defined. The input parameters arepre-selected, read-only parameters.

However, modification can occur for the mapping of the output parameters to therelevant data and the output parameter relevant data identifiers. The relevant datacan be modified or deleted, provided that it is not referenced by any input oroutput parameters, and new relevant data can be added. Adding or modifying anaccount triggers an entitlement workflow if it is associated with the provisioningpolicy that governs the account.

An account request workflow is invoked during:v New account requests from a IBM Tivoli Identity Manager userv Account modify requests from a IBM Tivoli Identity Manager userv Automatic account provisioning from the IBM Tivoli Identity Manager system

when automatic entitlement is defined in the provisioning policyv New access requests from a IBM Tivoli Identity Manager user, and there is no

access request workflow defined for that accessv Policy enforcement from a IBM Tivoli Identity Manager system. If an account

modify operation occurs because of a policy enforcement action, the accountrequest workflow for an account is executed only if the following property inthe enRole.properties file is set to false:enrole.workflow.skipfornoncompliantaccount=false

The default value is true.

Access request workflowsAn access request workflow is invoked during access provisioning for a requestfrom a IBM Tivoli Identity Manager user.

Planning 31

Use the Define an Access task for a service group to assign an access requestworkflow to a specific access. The access request workflow is invoked for thataccess when the access is requested by a IBM Tivoli Identity Manager user.

Within the IBM Tivoli Identity Manager system, an access provisioning request ismapped to an account provisioning request for a specific service, based on theaccess definition, such as the service and service group of the access.

If an access request workflow exists, the workflow is run to perform approval andvalidation of the access. The account request workflow is bypassed.

If there is no access request workflow, the applicable account request workflow isinvoked, based on the specification in the provisioning policy entitlement for theservice to which access is provisioned.

The access request workflow is invoked only during an access request. It is notinvoked during an account request, even if the access request workflow gives theuser the same access by assigning the account to a specific group.

Entitlement workflow parametersEntitlement workflows for accounts and access both have a fixed set of input andoutput parameters. The set cannot be modified by a IBM Tivoli Identity Manageruser.

The input parameters are:

Entity A relevant data item that represents the account or access that is actedupon.

For an account request workflow, the entity type for this entry is Account.If the operation is Add, this object contains the data for the new account. Ifthe operation is modify, this object contains the modified attributes.

For an access request workflow, the entity type for this entry isUserAccess, which is inherited from Account and contains the data for anew account or changes to an existing account, to provision the access. Italso includes other information for the access used internally by IBM TivoliIdentity Manager. When referencing this object in JavaScript, only the APIsdefined on Account can be used; the additional APIs to get accessinformation are not published and used only internally by IBM TivoliIdentity Manager.

ServiceA relevant data item that represents the service to which the account oraccess is associated. The entity type for this entity is Service.

OwnerA relevant data item that represents the person to whom the account oraccess belongs. The entity type for this entity is Person.

A single output represents the account or UserAccess entity for which the requestis issued. This output parameter allows changes that are made to the account orUserAccess object that is passed in to be communicated back to the provisioningsystem. For example, an RFI can be used to request that an administrator manuallyenter account values. The resulting account object is returned to the provisioningsystem with the values.

32 Planning

Workflow elementsOperation, account request, and access request workflows are made up ofprocesses and activities.

Workflows are made up of one or more of these elements:

ProcessesProcesses define the activities and flow between activities that are neededto execute a business process. Processes include these elements: activities,transitions, input/output parameters, and relevant data.

ActivitiesActivities represent the business logic for a specific task in a workflowprocess. An activity is represented in a workflow as a node.

IBM Tivoli Identity Manager supports the following types of nodes:v Approvalv Mailv Request for Information (RFI)v Operationv Loopv Extension activitiesv Scriptv Workorderv Subprocess, available only for account request and access request

workflows. You cannot include a Subprocess activity in an operationworkflow.

In order to support the business logic of an activity, input and outputparameters might be required. For activities, input and output parametersrepresent data being passed into and returned from the activity. You userelevant data to associate the input and output parameters of an activitywith any data that is stored in the process.

When sending notification messages from workflow activities, you canspecify dynamic content in those messages to personalize and customizethem appropriately. Dynamic content can also be used to customize theaction text for a workflow activity.

TransitionsTransitions represent a flow between two activities. When a workflowprocess is executed, the flow from one activity to another activity iscontrolled by the conditional logic (JavaScript coding) in the transitionsand the activity configuration information. You can define both serial andparallel flows with IBM Tivoli Identity Manager.

Input/output parametersInput and output parameters define the data that is passed into andreturned from a workflow process. Some workflow processes in IBM TivoliIdentity Manager might restrict the customization of input and outputparameters.

Relevant dataRelevant data defines global variable data for workflow processes. You canuse this variable data to pass data from one activity to the next byassociating it with activity parameters. Output parameters resulting from

Planning 33

an activity are stored as a relevant data data item. They are then passedfrom relevant data and become the input parameter for another activity.

Transitions can also access and use relevant data in their conditional logic.

Activity participantsActivity participants are IBM Tivoli Identity Manager users who have beenassigned to interact with activities in a workflow process, such asapprovals, mail, requests for information, and work orders.

An activity participant can be a specific user with a IBM Tivoli IdentityManager account or assigned to a particular organizational role, or a userwith a specific relationship, such as a supervisor or services owner.

Some workflow activities might restrict the list of available participants,while some activities (mail, work order activities) can be configured to notrequire the participant to be a IBM Tivoli Identity Manager user at all.

JavaScriptMany of the workflow elements, such as transitions and script elements,integrate the JavaScript scripting language in order to enable customizationof workflow processes. In addition to the standard JavaScript extensions,IBM Tivoli Identity Manager provides JavaScript extensions that you canuse to access processes, activities, relevant data, and participants.

Common attributes for workflow activitiesEach workflow activity has a set of attributes that must be configured in order forthe workflow to work properly.

To show the attributes menu for a node, double-click the node, or right click thenode and then click Properties. The following attributes are common for multiplenode types.

Activity IDThe Activity ID is a unique identifier for the node activity. The Activity IDis displayed below the node in the workflow designer and is a requiredfield. It must be a valid JavaScript variable name, and it must start with aletter. The Activity ID cannot contain any spaces or special characters otherthan an underscore (_).

Activity NameThe Activity Name is an optional, descriptive field that is used for severalactivities in the audit logs.

DescriptionThe Description is the optional, descriptive explanation of the activity.

Join TypeEach activity in the workflow has an attribute to define the split and thejoin criteria. This attribute is used to determine how the workflow enginewill process multiple paths into and out of an activity. Join types definehow the workflow engine will process the transitions into an activity. TheJoin Type is a workflow directive that synchronizes incoming transitions.The Join Type must match with a Split Type previously defined in theworkflow. The following are the Join Type values you can select:

AND The activity must wait for all active incoming transition paths to becompleted before initiating the activity.

Example: You have a split defined that leads to three parallelapproval activities and one of the split transition conditionsevaluates to “false.” Because only two of the approvals will

34 Planning

become active, only those two paths must be completed in orderfor the activity that is the point of join to execute.

OR The first path that leads to the activity that evaluates to true willcause this activity to execute. Because the order of transitionevaluation is undefined, the OR condition should only be usedwhen only one condition will evaluate to true.

Split TypeSplit types define how the workflow engine will process the transitions outof an activity. The Split Type is a workflow directive that synchronizesdiverging transitions. The Split Type must have a corresponding Join Typethat matches its condition as the workflow progresses. The following arethe Split Type values you can select:

AND All paths that leave the activity will be evaluated and all paths thatresolve to true will be followed.

OR The workflow engine evaluates transitions until it finds one thathas a condition of true. That path is then followed. The remainingpaths are not evaluated.

Manual activities (approval, RFI, work order) have the following commonattributes:

ParticipantThis attribute defines the user that is notified to respond to a request for amanual workflow activity. A Mail activity has a Recipient attribute insteadof Participant. The attribute defines the recipient type for mail. Forexample, a recipient might be a Person entity that has an e-mail account,an organizational role, or a group. When defining a custom recipient, theParticipant object must be used within the script for the recipient field ofthe mail node.

Escalation ParticipantThis attribute defines the user that is notified to respond to a request for amanual workflow activity if the original participant does not respond bythe time period specified in the Escalation Limit attribute. Escalationparticipant is an optional attribute. The escalation participant will also beused if there is a failure resolving the original participant. A Mail activityhas no escalation participant.

Escalation LimitThis attribute specifies the time before the request is escalated to theescalation participant. A Mail activity has no escalation limit.

Note: Participant, escalation participant, and escalation limit are onlyapplicable for human interactive activity types like approval, mail, RFI andwork order.

TransitionsTransitions are the pathways that connect various workflow activities. Nodes areconnected together with transition lines to form a workflow.

Each transition has a JavaScript component (condition) that is used to determinewhich transition, or path, should be followed. The JavaScript condition mustevaluate to true or false. If the condition is true then the transition is followed,depending on the split criteria.

Planning 35

When two or more of transition lines connect to the same node, the join type of thenode is evaluated. The join type can either be an And clause, indicating that alltransitions must be active to trigger the node, or an Or clause, in which case, anyone of the transitions that are active will trigger the node. The join type isindicated by a symbol on the left of the node, a triangle for the Or clause and acircle for the And clause.

The only required property for a transition line is the Condition.

Start and end nodesThe start node defines the beginning of a workflow and the end node defines theend of a workflow.

Start and end nodes are always included in a workflow and cannot be deleted.These nodes each contain a JavaScript window that allows you to add JavaScriptcode to execute at the beginning or end of the workflow. Start nodes only havetransitions out and end nodes only have transitions in.

Approval nodeUse the approval node to add a request for approval when adding or modifyingpeople, accounts, and access.

The approver must be a IBM Tivoli Identity Manager user, because the approver isrequired to log in to IBM Tivoli Identity Manager to approve or reject the request.

In entitlement workflows, use approval nodes to request authorization to continuewith a provisioning request. In operation workflows, use an approval node as aswitch to follow a specific workflow path.

Approval text and labels can also be customized to allow approvals to be used formost Yes/No decision activities.

Mail nodeUse the mail node to specify the recipient type and content to be e-mailed to auser in an e-mail notification.

The content can be specified directly or copied from a template used by mailactivities in other workflows.

Request for information nodeUse the request for information (RFI) node within entitlement and operationworkflows to solicit account or user-related information from a user with an IBMTivoli Identity Manager account.

Within the RFI, you specify the attributes for which the participant is being askedto provide values. Only attributes you select are editable by the participant. Allother form attributes are read-only. The page displayed in the Activities to-do listwill match the form specified using the form designer. Attributes listed asmandatory on the account form will also be mandatory for the RFI. ACI definitionsdo not need to be created for the fields that the participant is asked to respond to.

You must select an entity type and entity for the RFI to be used to requestinformation about attributes for a specific entity. Once the entity type is selected, alist of attributes is displayed to select from. The attributes selected will appear onthe RFI page when the participant logs in and accesses the RFI activity list item.

36 Planning

For example, if you select Account, then the account parameter must contain anentity for an account, such as ITIMAccount. If you select Person for the Entitytype, the parameter must be for an Entity such as Person or BPPerson. The list ofentity or account objects vary based on your implementation. For each accountprofile installed you have an entity listed when the account type is selected. Foreach user defined, you have an entity listed when the Person or BPPerson type isselected.

Operation nodeUse the operation node to invoke an existing operation from within a workflow.

The operation activity type can be Global, which requires that you specify anoperation. If the activity type is Data Reference, you must specify the data asEntity, Service, or Owner. If the activity type is Expression, Static, or Dynamic,select an Entity Type as Account, Business Partner Person, or Person. Dependingon your choice, also specify subordinate attributes such as a specific entity,expression, and operation.

The operation must be predefined for an entity type or entity. Operations takeinput parameters, but they do not return anything to the calling workflow.

The Activity ID and Operation properties are required.

Loop nodeUse the loop node to execute one or more nodes in a loop (nested loops are notsupported).

There are two types of loops:

Do whileThis loop will evaluate the condition prior to executing. If the condition istrue, the loop will execute, otherwise it will continue with the next node.This loop type is used when the condition is dependent on the workflowprocesses prior to the loop node. The process defined by the loop will notrun if the condition is already met.

Do untilThis loop will evaluate the condition after each execution of the loopnodes. The workflow completes the process defined in the loop beforechecking the loop condition. If the condition is true, the loop will executeagain, otherwise it will continue with the next node after the loop. Thisloop type is used if the process defined by the loop must run at least onceregardless of any previous activities.

Nodes contained within the loop must not transition to any activities outside theloop. All transitions should originate to and from the loop node. The standardrules for split and join apply for loops in terms of multiple transitions in andmultiple transitions out. The loop node does not specify the results of the nodes inthe loop. You must check the status of nodes in the loop in a script following theloop if required.

Because an activity in the loop can execute multiple times (once for each loopiteration), the workflow engine keeps track of activities in a loop by giving theman index representing which iteration of the loop that the instance of the activityapplies to. This index is stored in the activity object as a member variable called

Planning 37

index. For activities that are not in a loop, this index is set to 0. For activities in aloop, this value will be 1-n, where n represents the number of actual loop iterationsthat execute.

To retrieve a particular instance of an activity in a loop, use theprocess.getActivity() method. This method takes two arguments: the activity IDand the index of the target activity instance. If you use this method to retrieve anactivity that is not part of a loop, you can either omit the index argument or set itto 0. The method returns an activity object.

The condition defined in the loop specifies the number of loop iterations. Theglobal variable, loopcount, can be used to identify the current iteration of the loop.The loopcount variable starts with 1 (loopcount=1) and increments each time theloop is executed. This variable can be useful for creating loop conditions, forexample, loopcount<x.

Nodes placed in the loop determine the amount of time each loop takes. The loopnode does not have a built in wait mechanism.

The activity ID and the loop condition are the only required properties for the loopnode.

Getting activities within a loop:

Use the getActivity() call to retrieve an activity.

For example, the following call retrieves the supervisor approval activity associatedwith the third iteration of the loop:theActivity = process.getActivity(“SupervisorApproval”,3);

The following call retrieves the service owner approval activity that is not part of aloop:theActivity = process.getActivity(“ServiceOwnerApproval”);

An instance of an activity is not available for retrieval using process.getActivity()until the activity actually executes in the loop. If you have a loop condition thatspecifies that a loop should execute three times or until another condition is met, itis possible that the third iteration of the loop will not execute. In this case, a scriptexecuting the following line of JavaScript code after the loop will return a nullvalue.theActivity = process.getActivity(“SupervisorApproval”,3);

Accessing the Activity with a null value will cause errors to occur.

Extension nodeUse the extension node to invoke an application extension from within theworkflow.

The application extension is a Java™ class that has been preconfigured for use inthe workflow environment. Extensions can accept input parameters and returnoutput parameters back to the workflow. Only extensions that have been properlyregistered will appear in the extension window.

System-defined extensions define basic, atomic services provided by IBM TivoliIdentity Manager. These building blocks are the components with which standard

38 Planning

operation workflows are built. Workflow extensions make it easy to incorporatecore IBM Tivoli Identity Manager services and functions into various IBM TivoliIdentity Manager workflows.

Although operation extensions are components of operation workflows, they canalso be used outside of an operation workflow. They can also be called inentitlement workflows.

For example, assume that during account provisioning you want to execute achange to the account owner’s user record in the IBM Tivoli Identity Manager userstore. You can include the modifyPerson extension into the entitlement workflowto accomplish this. If you want to have the business logic associated with themodify user operation, you can also include the modifyPerson operation in theentitlement workflow. Refer to the operation node for more information onincluding an operation into an entitlement workflow.

You can also create your own custom application extensions and add them to aworkflow.

Script nodeUse the script node to add logic to the workflow through the use of JavaScriptcode.

The Script node makes clear to anyone viewing the workflow that scripting ispresent in the workflow.

JavaScript code is used within workflows to dynamically define and retrieveparameter and attribute values and to store and forward these values as variablesfor use by logic or code within a single workflow activity.

The JavaScript code can be extended by defining custom JavaScript objects througha Java extension.

When using the Script node, carefully consider the overhead associated withexecuting additional activities in a workflow versus using post activity executionscripts on existing activities. Also consider combining multiple sequential scriptactivities into a single script node to avoid additional workflow transactionoverhead.

The Activity ID is the only required property for the Script node.

Work order nodeUse the Work order node to send e-mail to a IBM Tivoli Identity Manager user,either to request some type of manual activity or as a simple notification.

The work order activity supports two execution modes: send and send and waitfor completion. The send mode completes the activity when the work order requestmessages are successfully sent to the mail server for forwarding to participants.The send and wait for completion mode sends the e-mail and then waits fornotification of the completion of a manual activity.

The activity ID and Participant properties are the only required properties for thework order node.

Work order workflow participant resolution:

Planning 39

Work orders interact with end users differently, based on the setting for send orsend and wait for completion. The setting also changes the behavior of participantresolution. In the send-only mode, only participants with e-mail addresses will beresolved. Send mode only e-mails a notification. If no e-mail address is specifiedfor the user, the user is not a valid workflow participant.

If the send and wait for completion option is specified, an e-mail is sent and thework order waits to be completed through the activity list or the external API.Participant resolution considers users who own IBM Tivoli Identity Manageraccounts and users who do not own Tivoli Identity Manager accounts but havee-mail addresses. If a resolved user has a Tivoli Identity Manager account, a workorder entry is added to the user’s activity list. E-mail notifications are sent to userswith Tivoli Identity Manager accounts and an e-mail address, and to users withonly an e-mail addresses (but no Tivoli Identity Manager accounts).

The Continue on Participant Resolution Failure option is available in the WorkOrder node of the user recertification workflow designer. If you select this option,the workflow process continues in event of a participant resolution failure.

Subprocess nodeUse the subprocess node to execute one entitlement workflow from another.

Subprocesses simplify the workflow by using one node to represent a previouslydefined workflow sequence.

Note: The Subprocess node is not available for use in Operation workflows.

Subprocess nodes are typically used for the following reasons:

OrganizationWorkflows can become very complicated when there are many parallelbranches that must execute. Placing large blocks of processing into asubprocess can sometimes help.

ReusabilitySubprocess workflows that define generic processing can be included inmultiple workflows.

A subprocess can utilize any predefined entitlement workflow of the same servicetype (or global workflows); however, the workflow must be located within thesame organization.

You must map the parameters required by the child workflow to relevant dataitems in the parent workflow. The subprocess node provides the set of input andoutput parameters for the Subprocess. While the parameter names and types arefixed by the subprocess node, you can configure the value of each parameter.

The Activity ID and the Subprocess property are the only required properties forthe subprocess node.

Workflow dataWorkflow data consists of the information that is input to and output from theactivities that comprise the workflow.

The following types of data are used to build workflows:v Relevant data objects

40 Planning

v JavaScript variablesv Workflow context objects

Relevant dataRelevant data defines global variable data for the workflow process.

Relevant data is used to pass data from one activity to the next by associating itwith activity parameters. Relevant data can be accessed through JavaScript for usein transition conditional logic, script activities, and post activity scripts.

Relevant data consists of the following attributes:

ID The relevant data ID is its name. For example, user. This ID is used toreference the relevant data item when associating it to activity parametersor accessing it in JavaScript. The ID cannot contain any spaces or specialcharacters other than an underscore (_).

Type The relevant data container is the type of data. For example, Person,Account, Distinguished Name, List, Integer, String, and so on.

Entity Used with certain relevant data types to specify the profile type. Forexample, with Account-type relevant data the Entity could beITIMAccount.

Element TypeUsed with the List type to specify what type of items are stored in the list.

For lifecycle operations that you want to enhance with additional functionality, youmight have to add additional relevant data items and JavaScript code to retrievevalues for those items from the directory. For example, assume you want totransfer a user to another location within the organization whenever amodifyPerson operation is performed that changes an attribute related to theuser’s job function. You would need to define relevant data that applied to theorganizational container in which you were placing the user.

Input and output parameters:

Workflow input parameters are data items that are used to perform a function.Workflow output parameters are data items that result from an activity.

Workflows are processes that are comprised of a series of activities. Activitiesrequire input data to act upon. Activity output can be mapped to another activity’sinput through relevant data.

Both input and output parameters are supported in operational workflow andentitlement workflow processes.

Parameters for workflows must be mapped to a workflow or relevant data item.The values for these parameters can then be used as parameters for a subsequentworkflow activity.

System-defined data:

System-defined data are default global data items (input parameters and relevantdata) that have been defined for use by the workflow engine.

For example, the add user operation defines input parameters for the user to becreated and the organization tree level container in which to create them. These

Planning 41

data items are available to the entire workflow and any activities and nodescomprising the workflow can make use of them.

System-defined input parameters are predefined for each default operation andvalues are set for you prior to the execution of the workflow. However, while youcan use JavaScript code to modify these values, you are not allowed to create newinput parameters for the entire workflow.

System-defined relevant data can be predefined, and values are set for you prior tothe execution of the workflow. You can use JavaScript code to modify these valuesand you are allowed to create new relevant data for the entire workflow. However,you cannot remove existing system-defined relevant data items, or you riskcorrupting the default business logic behind the workflow.

User-defined data:

You can create new relevant data items to use within a workflow to hold data thatmight be used in more than one activity, or to receive the output of an applicationextension.

To store data in the relevant data items, you must first create the relevant dataitem with the appropriate data type. You can then, optionally, initialize the dataitem using JavaScript code, but you are not required to. Relevant data can also bepopulated by mapping it to the output parameter of an activity.

Context of relevant data items:

When you define a relevant data item, you can associate it with a context.

The context of a relevant data item specifies the entity to which the item applies.The context of a relevant data item can be used to determine workflow participantsand is useful for audit purposes. You define the context of a relevant data itemwhen you define the item. The possible values for context are:

Not ApplicableSpecifies that this data item has no context.

SubjectIdentifies that this data item is the subject of the workflow. You can defineonly one subject per workflow. For example, in an entitlement workflowfor:v Account, the account is the subject.v Access, the access is the subject.

RequesteeIdentifies that this data item is the user to whom this workflow applies.The requestee for an entitlement workflow is the account owner. You candefine only one requestee for a workflow.

Both Identifies that this data item applies to both the subject and requesteecontext.

Workflow data in JavaScript codeData items that represent IBM Tivoli Identity Manager entities are represented inJavaScript code as DirectoryObject objects.

DirectoryObject objects have methods and instance variables that can be accessedin JavaScript code.

42 Planning

The data item types that represent Tivoli Identity Manager entities include:v Accountv Admin Domainv Business Partnerv Business Partner Organizationv Business Partner Personv Business Unitv DirectoryObjectv Host Selection Policyv Organizationv Organizational Containerv Organizational Rolev Personv Provisioning Policyv Service

Workflow data persistence:

When you call a get method on a relevant data item, you load the data from thepersistent data store into an in-memory cache. If another activity in the workflowcalls a get method on the same data item, it uses the same cached copy.

When you use the addProperty, setProperty or removeProperty methods, youupdate the cached copy of the data. The set method writes your changes from thecache back to the persistent data store.

The addProperty, setProperty, and removeProperty methods do not automaticallywrite their changes to persistent storage for two reasons: performance and dataintegrity. There is a performance cost associated with each write process. Tominimize overhead, a single write process can be executed after all attributes havebeen modified. Think of the set method as a database transaction commit. Youwould not want the persistent storage to be updated with only a portion of yourchanges if the server suddenly became unavailable. Using the set method as atransaction commit allows all or none of the changes to be committed to persistentstorage.

Workflow context objects:

You can access a number of system objects directly from JavaScript code withoutusing a get method. These system objects are referred to as context objects.

Workflow context objects are exposed to the workflow scripting environment asglobal JavaScript objects. Other JavaScript contexts have global data available tothem, but only the following global objects are related to workflow:

ActivityThis object contains the information related to the current activity.

ProcessThis object contains the information related to the current process.

Planning 43

Workflow participantsA workflow might contain activities that require manual intervention or input by auser before it can be completed. This user is called a workflow participant.

When an activity requires an action before it can continue, an activity to-do item isassigned to the participant. The item appears in the participant’s Activities to-dolist, which the participant can view the next time the participant logs on to IBMTivoli Identity Manager. This to-do item might consist of a participant approvingor rejecting a request, providing the activity with information for it to process, orcompleting a manual task outside of the system. When a participant completes theto-do item, the activity can proceed.

Workflow participants must have an IBM Tivoli Identity Manager account torespond to approval requests and requests for information.

In order for a workflow participant to respond to work order requests that must becompleted before the workflow can continue, the participant must have a valide-mail address or a IBM Tivoli Identity Manager account.

For each activity that requires a participant, you can also specify an escalationparticipant.

When you specify an escalation participant, you define a time limit that is used todetermine when the request should be escalated. If the original participant cannotbe resolved or does not respond within the specified time, the escalationparticipant is notified. If for any reason the participant and the escalationparticipant cannot be resolved, the System Administrator group becomes theworkflow participant.

A manual activity has performance considerations if you select a participant oftype ITIM Group or Organizational Role. If the membership of the group or role isvery large, such as greater than 1000 members, the system might have problemscreating activities for each individual.

Additionally, you might redesign a workflow process that the process authorizesmany individuals to approve an activity. For example, when you select theparticipant for a workflow activity, an approval that goes to an ITIM Group or anOrganizational Role sends the approval to each member of that group or role. Theactivity is completed as soon as any one member of the group or role (in thisexample, containing over 1000 members) takes an action on the approval.

Workflow participant typesWorkflow participants can be specified by the participant type, includingsystem-defined participant types and custom (user-defined) participant types.

IBM Tivoli Identity Manager provides the following types of workflowparticipants:

Person (with e-mail account)The participant is a specific user who has an e-mail account, and mustrespond to the request.

Person (with ITIM Account)The participant is a specific user who has an ITIM Account, and mustrespond to the request.

44 Planning

Organizational RoleThe participant is a specific organizational role.

If the role is a child role of another organizational role, which thenbecomes a parent role, then that child role inherits the permissions of theparent role. Therefore, the notification is sent to both the organizationalrole and its child roles. All user members of the organizational role and itschild roles are eligible to respond. The first response from any usermember or child role triggers the workflow to continue.

If you need to delete an organizational role, first check that no workflowdefinitions refer to the role to avoid any possible problems with participantresolution.

ITIM GroupThe participant is a Tivoli Identity Manager group. All members of thegroup are notified, and all members are eligible to respond. The firstresponse triggers the workflow to continue.

RequestorThe participant is the user that initiated the request.

RequesteeThe participant is the user or account being acted upon by the request. Foraccounts, the account owner is generally the requestee.

Service OwnerThe participant is the owner of the service, as specified in the relevant dataaccount object.

Access OwnerThe participant is the owner of the access, as specified in the relevant dataaccount object. This type is only available in the access request entitlementworkflow designer.

Role OwnerThe participant is the owner of the role, as specified in the correspondingrelevant data. This type is only available in the workflow designer foroperations.

SponsorThe participant is the person who is designated as the sponsor for therequestee. This is only applicable to business partners.

ManagerThe participant is the supervisor or manager of the requestee. If a manageris not specified for the requestee, the manager who is designated on theorganizational container of the requestee is the participant. If no manageris specified for the organizational container, the next level up in theorganizational tree is checked for a manager, until the top of theorganization is reached.

System AdministratorThe participant is the System Administrator group. One of the members ofthe System Administrator group is required to take action before theactivity can continue.

Domain AdministratorThe participant is the domain administrator of the organizational containerthat is associated with the subject of the request. If the subject is an:v Account, UserAccess, or Service, then the service that the subject refers

to will be used to determine the organizational container.

Planning 45

v If the subject is not Account, UserAccess, or Service, then the requesteeof the workflow process is used to determine the organizationalcontainer.

Custom ParticipantThe participant is determined with a JavaScript expression. The JavaScriptexpression must return one of the system-defined participant types.

Custom workflow participantsYou can define custom workflow participants using JavaScript code.

A user-defined workflow participant is referred to as a custom participant type. Toimplement a custom participant or a custom recipient (in case of a mail node), youmust create an object of type Participant.

Skip approval for requester propertyIn some cases, the requester of an activity can also serve as a workflow participant.

If the requester of an activity is also designated as a workflow participant, theapproval request for the requester is always skipped by the workflow.

Use the enrole.workflow.skipapprovalforrequester property to specify whetherother participants are skipped. The enrole.workflow.skipapprovalforrequesterproperty is defined in the enRole.properties file.

If the property is set to true, IBM Tivoli Identity Manager skips approval for otherresolved participant users if the requester (the user who submitted the request) isidentified as one of the participant users (as the result of participant resolution).Thus, the approval is completely skipped.

If the property is set to false, then the requester is skipped, but approval still goesto the other resolved participants.

Notification of failed workflow requestsIBM Tivoli Identity Manager sends e-mail alerts for all failed workflow requests,including reconciliation, to the requester.

For system-generated processes, such as scheduled reconciliations, the e-mailnotification is sent to the system administrator.

46 Planning

Index

Aaccess control 12, 13, 14, 16access entitlements 14activities in workflows 33application extension 38approval node 36

Ccommon attributes, workflow

activities 34conflicts 7, 12context object in workflows 43custom participant in workflow 46

Ddata persistence in workflow,

JavaScripts 43default 12

Eelements, workflow 33end node 36entitlement workflow parameters 32entitlement workflows 30

access 32accounts 30

entity type targets 13Extension node 38

GgetActivity() call in loop node 38groups

membership 6

Iidentity feed

planning 2input and output parameters 41

JJavaScript data in workflows 42

Lloop node 37loop node, getActivity() 38

Mmail node 36

Nnodes in workflows 33nonstatic operations 27

Ooperation node 37operation workflows 26operations

nonstatic 27static 27system-defined 28user-defined 30

organizationplanning

role 19

Pparticipant in workflow 44participant types in workflow 44password

policy 4planning

identity feed 2initial conditions 4organization

role 19people 1

policypassword 4

processes in workflows 33

Rrecertification policies 16relevant data 42relevant data in workflows 41request for information node 36RFI node 36role

organization tree 19planning 19

Sscript node 39set method 43skip approval for requester property 46start node 36static operations 27subprocess node 40system-defined data 41system-defined operations 28

Ttransitions in workflows 35

treeplanning

role 19

Uuser-defined data 42user-defined operations 30

Vview 7

Wwork order node 39work order participant resolution 40workflow participant resolution 40workflows

activities 34data 40

context objects 43input and output parameters 41JavaScript 42persistence 43relevant 41relevant data 42system defined 41user defined 42

elements 33entitlement 30

access 32accounts 30

entitlement parameters 32Extension 38levels 27node 38

approval 36end 36loop 37mail 36operation 37script 39start 36subprocess 40work order 39

notification, failed request 46operation 26participant 44

custom 46skip approval 46types 44

planning 26request for information

node 36static and nonstatic operations 27system-defined operations 28transitions 35user-defined operations 30

47

sim planning

Documents

workflow planning

identity recordsthat

identity policyconcatenates

security planning

default identity policy

role planning

preinstallation planning

planning informationhelps