Role recertification in Tivoli Identity Manager

IBM Tivoli Identity Manager

In IBM® Tivoli® Identity Manager (ITIM), organizational roles help to simplify and automate the process of provisioning and de-provisioning user privileges to IT and non-IT resources. In addition to the user and account lifecycle management that ITIM provides, workflows can also assist with the lifecycle management of user role memberships, such as role assignment and role approval. Another important process is validating the continued business need for a person to be a member of a role. This process is known as role recertification or attestation. ITIM version 5.0, introduced a number of enhancements that allow users to request role assignments and have those requests approved by the role owner. Recertification of user role membership is another role management process that can be built in ITIM 5.0, and this process can be implemented in a number of ways. Although ITIM 5.0 does not provide this functionality in a ready-to-use interface, this article discusses a number of solutions for implementing role recertification in ITIM 5.0.

Chris Choi, IT Specialist, IBM

Chris ChoiChris Choi is an IT specialist in the Tivoli Security Team based on the Gold Coast, Australia. Chris works in a customer related role, participating in both pre-sales and post-sales activities in Asia Pacific.


developerWorks Contributing author
        level

Patricia Saunders (psaunders@uk.ibm.com), Tivoli Security Worldwide Enablement Specialist, IBM

Patricia SaundersPatricia Saunders is an IT Specialist for the Tivoli Security Worldwide Sales enablement team based in Dallas, Texas. In this role, she supports IBM field personnel and Business Partners providing skills transfer for IBM Tivoli security products. She has 10 years of experience working with IBM Tivoli and has spent the last three years focusing on the IBM Tivoli Identity Management family of products. She holds a masters degree in computing systems management from Houston Baptist University. She has contributed to other IBM Redbook topics such as security architecture, Tivoli Identity Management, and Tivoli Directory Integrator.



Leanne Chen (lianchen@us.ibm.com), Tivoli Security Software Architect, IBM

Leanne ChenLeanne Chen is a software architect for Tivoli Identity Manager in the Tivoli Security Software Development Lab based on Costa Mesa, California. Leanne has been leading the design and development work of Tivoli Identity Manager for many years.



08 August 2008

Introduction

Recertification policies

ITIM uses recertification policies to automate the revalidation of entitlements granted to a user. The policy is flexible enough so that any subset of entitlements (accounts or accesses) can be acted upon for recertification. ITIM also allows varying types of schedules to be set up for the execution of these policies. Notifications and approval events are sent to the policy participants and workflow activities are initiated based on the recertification policy specification. The actions taken in a recertification policy are audited and a set of recertification reports can be produced.

Recertification policies can only be used on a specific service or service type.

Software versions

ITIM 5.0 Fix Pack 1 was used for this article. It is likely that the examples discussed in this article will also work on later fix packs, but the authors' testing was limited specifically to Fix Pack 1 level.


Solution overview

This article presents the two approaches for implementing role recertification in ITIM. The following sections briefly describe each approach and the details on how to implement the suggested solution. We also provide some discussion on the pros and cons for each solution.

Using the lifecycle rule

The lifecycle rule was first introduced in ITIM 4.6 to allow execution of defined business logic on a scheduled basis. One solution for role recertification is to use a lifecycle rule to trigger the role recertification process, in which the recertification process is defined using the lifecycle operation. In the lifecycle rule definition, a filter can be used to specify the people who would be affected. This approach gives you the flexibility of having a specific recertification process for a set of users and a specific set of roles. The drawback of this approach is that the recertification action is not audited and the recertification data is not included in the recertification reports, including the Recertification Policy Report and the Recertification Change Report. However, customized reports are required to support auditing and reporting requirements, for example, building these reports through the common reporting tool based on Business Intelligence and Reporting Tools (BIRT).

Using recertification policy on ITIM service

An alternate solution for role recertification is to define recertification policy for ITIM service and trigger the role approval for the ITIM account owner in the ITIM account recertification process. This approach works well if each user has only one ITIM account and there is no need to recertify the ITIM account, otherwise there would be a conflict.

The main advantage of this solution is the fact that it utilizes all the features of recertification policy such as an intuitive user interface, recertification scheduling, and recertification-specific auditing and reports.


Solution implementation

In the following sections, we explain the details of how to support role recertification using the two approaches described above.

Using lifecycle rule

In the case that the auditing and reporting is NOT required for role recertification, this approach works well and it has the flexibility to support different role recertification scenarios:

  • One recertification configuration applies to all people for all roles
  • The recertification schedule is different for different sets of people
  • The recertification process is different for different sets of roles

Using the case that recertification configuration applies to all people for all roles, here are the steps required to support role recertification:

  1. Create a Global Role Owner Approval operation using a global level lifecycle operation as shown below. Lifecycle operations are defined in the Configure System > Manage Operations task.
    Figure 1
  2. For this operation, define a simple approval workflow. The workflow has a Start, Approval and End node.
    Figure 2
  3. Two new input parameters for this operation are defined below. Click the Properties button to Add the input parameters. A new input parameter is defined to contain the role to be approved.
    Figure 3
    Another input parameter is defined to contain the person who has the role.
    Figure 4
    The resulting Properties page looks like the one below.
    Figure 5
  4. Define the Approval Activity node as shown below:
    Figure 6
  5. The approval activity Action Text is modified to show the Role Name in the Role Approval To Do item:
    Figure 7
  6. The approval activity Postscript is used to pass the activity result to the calling process, which we define later.
    Figure 8
  7. Next, define a RecertifyRole operation as a lifecycle operation for Entity Type "Person". Custom operations are defined in the Configure System > Manage Operations.
    Figure 9
  8. Define a workflow that calls the Global operation that we defined earlier and then a person modify operation. Here is what the basic workflow elements should look like before configuration:
    Figure 10
  9. Click the operation workflow Properties button to set the operation as a Non Static operation and add the relevant data items for the RecertifyRole operation workflow.
    IDContentTypeDefault
    ID: roleListContext: SubjectType: ListElement Type: Organizational Role
    ID: approvalOperationContext: NAType: StringDefault Value: Global Role Owner Approval
    ID: accountSuspendContext: NAType: StringDefault Value: false
    Figure 11
  10. In the Start activity, add the following JavaScript. This script sets the value of the roleList relevant data item. This list contains the user’s roles we want to go through in the recertification process.
    Figure 12
  11. Now configure the first extension. Use the approveRolesWithOperation workflow extension to invoke the previously defined Global role approval process: Global Role Owner Approval
    Figure 13
  12. Invoke the Person Modify operation to update the person with the approved roles in the directory; the rejected roles will be removed. The Person Modify operation also enforces policy for the person. The Operation node is configured as shown below.
    Figure 14
    The resulting operation workflow definition is shown below.
    Figure 15
  13. The final step is to define the lifecycle rule to set up role recertification for a set of people and a set of roles. These are configured in the Configure System > Manage Lifecycle Rules task. Here we Add a new rule. In this example, we assume that the role recertification configuration applies to all people and all roles. We simply use a LDAP filter to find people who currently have roles assigned. The Recertification rule is defined for the "Person" entity type:
    Figure 16
    Here is the General page of the rule definition specifying the operation.
    Figure 17
    Here is the Event page of the rule definition in which we specify the filter for people selection and define the recertification schedule. This filter returns all users who have roles defined and the role is not “ITIM Administrators”. Because erroles contains the role DN and not the role name, we must specify the erglobalid of the role to be excluded from selection.
    (&(erroles=*)(!(erroles=erglobalid=0000000000000001*)))
    Figure 18
  14. Test the Role Recertification Life Cycle Rule.
    Figure 19
    In this scenario, a user, Test User1 is assigned to the Developer role and the Project X role. In this example, Dan Meyers is the role owner for Developer and Mike Thompson is the owner for Project X.
    Figure 20
    The detail of the TO DO Activity item shows the individual role approval request:
    Figure 21
    Here, the second role was rejected by the Role Owner, Mike Stevens.
    Figure 22

The solution described above can easily be refined to recertify a specific set of people and roles by using a different filter.

In case the recertification process is different based on people or roles, multiple recertification operations will be defined for each process, and the lifecycle rule will be defined for each operation specifically. Each lifecycle rule allows a specific schedule to be defined.

The lifecycle rule should be configured in a way so that there is no overlapping of affected roles for the same set of people.

If auditing is required to keep track of the recertification activities for user roles, additional customization is required so that the recertification timestamp can be persisted to a data store. A simple way to do this is to extend the person's schema to include additional attributes on the person object to record this information. The recertification operation needs to update this attribute every time a recertification is triggered for a person for a specific role.

Using recertification policy on ITIM service

If every user has an ITIM account and there's no recertification policy already defined on the ITIM service, then this approach will provide a much simpler and better integrated solution.

Below are the steps that are required to implement this solution.

  1. Define the role approval process using a global lifecycle operation. This step is identical to the step for the lifecycle rule solution. Please refer to the previous section for more detail.
    Figure 23
  2. Define a recertification policy for ITIM service. The general page of the recertification policy definition is shown below:
    Figure 24
  3. Because we are using the ITIM account, select accounts
    Figure 25
  4. Then add the ITIM service
    Figure 26
  5. Pick an appropriate schedule
    Figure 27
  6. Select the Advanced option to launch the workflow designer. A custom workflow will be created to process the role recertification.
    Figure 28
  7. From the Properties view, define the following Relevant Data
    • accountSuspend
      Figure 29
    • isThereRoles
      Figure 30
    • rolelist
      Figure 31
    • customApprovalOperation
      Figure 32
  8. The resulting configuration of relevant data should appear as below:
    Figure 33
  9. In the START activity, use the following Javascript to test if the user has roles defined. A flag is set, isThereRoles, to indicate if there are roles defined.
    var roles = Owner.get().getRoles();
    if(roles.length > 0)
    {
        isThereRoles.set("y");
        rolelist.set(roles);
    }
    else
    {
        isThereRoles.set("n");    
    }
    Figure 34
  10. From the START activity, now set the transition lines based on the role flag, isThereRoles. From START to END activity - no roles defined, so we will exit.
    isThereRoles.get() == "n"
    Figure 35
    From START to Extension activity - roles exist and will go through recertification processing.
    isThereRoles.get() == "y"
    Figure 36
  11. Define the extension to perform the role approval (recertification). The extension used is approveRolesWithOperation. The operation name is the Global workflow we defined earlier, Global Role Owner Approval.
    Figure 37
    Set the Relevant data items for both Input and Output.
  12. On the Postscript for the Extension, set the result information with the following:
    WorkflowRuntimeContext.setProcessResult(WorkflowRuntimeContext.getActivityResult());
    WorkflowRuntimeContext.setProcessResultDetail( \
                                WorkflowRuntimeContext.getActivityResultDetail());
    Figure 38
  13. Set the transition lines from the ApproveRoles extension as follows: ApproveRoles to END - the Activity Failed.
    WorkflowRuntimeContext.getActivityResult()=="SF"
    Figure 39ApproveRoles to Operation - the Activity Succeeded.
    WorkflowRuntimeContext.getActivityResult()!="SF"
    Figure 40
  14. Define the Operation ModifyPerson. This operation will update the user’s role list based on the roles approved and rejected.
    Figure 41
  15. The Recertify extension will update the recertification status of the ITIM account for the person.
    Recertify Extension
  16. Test the Role Recertification Policy. Using the same scenario as the previous example, a user, Test User1 is assigned to the Developer role and the Project X role.
    Figure 42
  17. In this example, Dan Meyers is the role owner for Developer and Mike Thompson is the owner for Project X. Mike rejects the recertification of role Project X.
    Figure 43
  18. The recertification status for the user’s ITIM account is also updated.
    Figure 44

At the time of writing, not all recertification reports would work with the recertification policy for roles. For example, "Recertification Policies Report" works correctly but "Pending Recertification Report" does not. As it was mentioned previously, BIRT can be used to address these limitations in reporting.


Conclusion

This article demonstrated that a number of simple ITIM customizations can be used to implement role recertification in ITIM. Being able to request roles provides a greater flexibility in he ITIM request-based and role-based provisioning model. When coupled with the role recertification solutions discussed in this article, a wide range of business requirements can be realized.


References

Resources

  • Share your questions and views on this article with the author and other readers in the Tivoli Security Discussion Forum .
  • To learn more about Tivoli Security, visit the developerWorks Tivoli zone . You'll find technical documentation, how-to articles, education, downloads, product information, and more.
  • Get involved in the developerWorks community by participating in developerWorks blogs .

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


  • BlueMix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Security

    Pragmatic, intelligent, risk-based IT Security practices.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Tivoli
ArticleID=322598
ArticleTitle=Role recertification in Tivoli Identity Manager
publish-date=08082008