Request-based role assignment in Tivoli Identity Manager

IBM Tivoli Identity Manager

In version 5.0, IBM® Tivoli® Identity Manager (ITIM) introduces several new features to enhance its request-based provisioning model. Request-based provisioning allows users to request access to enterprise resources via a self-service interface. To better abstract the user from the details of the IT systems, ITIM 5.0 allows a user to request a role assignment. This greatly increases the flexibility of the request-based provisioning model,because a role can be associated with multiple entitlements. This article discusses a number of use cases for the request-based role assignment and demonstrate how these use cases can be realized via ITIM.

Share:

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

Trevor Norvill (tnorvill@au1.ibm.com), IT Specialist, IBM

Trevor NorvillTrevor Norvill is a customer facing Engineer based on the Gold Coast in Australia. Trevor works with Tivoli Security products in both pre-sales and post-sales engagements.



08 July 2008

Introduction

Prior to version 5.0, ITIM had a strong focus on the role-based provisioning model. The strength of this model was that the provisioning process was mostly automated and strictly controlled by the provisioning policy. However, the role-centric model meant that the role definition was a prerequisite to any ITIM implementation. Unfortunately, many customers struggled to define a concrete set of roles for their organization and preferred flexibility and simplicity of the request-based model. To address this trend, ITIM 5.0 introduced a number of features to more readily enable request-based provisioning. This article compares these features, highlights several use cases, and shows an example of how the new features of ITIM 5.0 can be used to implement an enterprise provisioning solution.


Provisioning models

Customers can now choose one of the two provisioning models or a hybrid provisioning model to best meet their business needs. The two major models are role-based provisioning and request-based provisioning. The new hybrid model is request-based role assignment.

Role-based provisioning model

In a role-based provisioning model, role changes are driven from a human resources system or by an authorized administrator. The provisioning system evaluates its policy and provisions access to the required business resources. When access is granted, the relevant users can then access the systems. Figure 1 shows a typical role-based provisioning system.

Figure 1. Role-based provisioning
Role-based provisioning

Request-based provisioning

In a request-based provisioning model, access to business resources is requested by users. The provisioning system evaluates its policy and its provisions access to the required business resources. Figure 2 shows a typical request-based provisioning system.

Figure 2. Request-based provisioning
Request-based provisioning

Request-based role assignment

ITIM 5.0 has two mechanisms for request-based provisioning. A user can request an account or an access. One of the draw backs of this approach is that only one account or access can be requested at a time. This might not allow the user to be sufficiently abstracted from the details of the IT system. To simplify the request-based provisioning model, a role can now be associated with multiple entitlements. This allows the users to indirectly request multiple accounts and accesses at the same time. For example, an employee might need an access to the corporate portal application. If the portal application is hosted behind the IBM Tivoli Access Manager (TAM) WebSEAL, in order to access the portal application the employee would need a TAM account and a portal account. The fact that a TAM account and a portal account are needed is irrelevant to the employee. All the employee cares about is accessing the portal application. By simply exposing these entitlements in a role, you provide the employee with an ability to request everything needed to access the portal application. It also provides a way to abstract the implementation details of how the access is provisioned.


Use cases

There are several use cases that would benefit from the request-based role assignment feature. The use cases described below are only a subset of these use cases.

Multiple accesses on a single system

In ITIM 5.0, an access consists of an account and a single group membership on a managed system. A single access cannot be associated with multiple group memberships. For example, if a user requests an access to a resource that requires the user to have an account belonging to multiple groups, this cannot be achieved in a single step. The user needs to request for multiple accesses, although logically they form a single access. When a role is used instead, multiple accesses can be requested at one time.

Multiple accesses on multiple systems

In some organizations, an access to a resource might require multiple accounts to be set up. The portal application behind the WebSEAL (a reverse proxy server), which was mentioned before, is a good example of this. Again, allowing the users to request roles will solve the problem.


Example implementation

This example outlines how request-based role assignment can be used to allow the staff at a fictitious company, OnDemand Inc., to request access to critical business applications. High level requirements are defined for the solution then sample configuration steps are shown. Lastly, the provisioning experience is demonstrated from the user's perspective.

Requirements

OnDemand Inc. has the following requirements for the enterprise provisioning solution to their portal application:

R1) OnDemand Inc. has an intranet portal application that runs on WebSphere® Application Server.

R2) The portal application consists of a main unprotected page and two protected sections for Sales and Distribution.

R3) OnDemand Inc. wants to allow staff to request access to their sales or distribution portal pages.

R4) OnDemand Inc. requires that managers first approve all requests prior to the staff gaining access to the portal applications.

R5) Single sign-on (SSO) must be achieved to the portal application.

R6) For employees to access the sales or distribution sections of the intranet portal, two provisioning operations need to take place:

1) Access to the OnDemand Inc. portal application is granted by creating an account with a specific group membership in the WebSphere user registry. To access the sales portal, the staff must be added to the sales group. To access the distribution portal, staff must be added to the distribution group.

2) A Tivoli Access Manager account needs to be created for each user that wants to access the protected portal pages.

Implementation

The OnDemand Inc. portal application infrastructure is shown in Figure 3. The OnDemand Inc. portal application is protected by Tivoli Access Manager WebSEAL. WebSEAL is configured to route requests to the OnDemand Inc. Portal application and Trust Association Interceptor (TAI) is configured to achieve single sign-on (SSO) between these two components. This satisfies requirement R5.

Figure 3. OnDemand Inc. portal infrastructure
Figure 3. OnDemand Inc. distribution page

OnDemand Inc. uses Tivoli Identity Manager as their strategic platform for provisioning. To provision accounts for the OnDemand Inc. portal, the following services are defined:

1) An LDAPDistribution service that provisions LDAP accounts and group membership to the OnDemand Inc. registry server

2) An LDAPSales service that provisions LDAP accounts and group membership to the OnDemand Inc. registry server

3) A TAM combo service that provisions TAM accounts

This satisfies requirements R3 and R6.

Creating roles

To allow employees to gain access to the sales and distribution application, the OnDemand Inc. administrator sets up two roles in Tivoli Identity Manager. This supports requirement R2 and R3. The OnDemandDistributionRole is used to allow users to request access to the Distribution portal application. The OnDemandSalesRole is used to allow users to request access to the Sales portal application. By checking the "Show this role in the access user interface" and "Show this role as a common access" checkboxes when creating a role, these roles are available as access entitlements to the user through the TIM 5.0 self-service console. The role owner is set to "Mike Stevens". The Role owner is used for the approval process. Figure 4 shows how to create a role for the distribution application.

Figure 4. Creating a role for distribution application
Figure 4. Create role for the distribution application

Creating provisioning policies

The newly created roles now need to be associated with provisioning policies so that the users can be provisioned with the required set of entitlements via the role assignment. The following provisioning policies are defined for this example:

1) Sales portal access policy: This policy associates OnDemandSalesRole to TAM and LDAPSales service entitlements.

2) Distribution portal access policy: This policy associates OnDemandDistributionRole to TAM and LDAPDistribution service entitlements.

Figure 5 shows the Sales Portal Access Policy.

Figure 5. Sales portal access policy
Figure 5. Sales portal access policy

Figure 6 shows the Distribution portal access policy.

Figure 6. Distribution portal access policy
Figure 6. Distribution portal access policy

Figure 7 shows the Sales portal entitlement configuration.

Figure 7. Sales portal access policy entitlement
Figure 7. Sales portal access policy entitlement

Figure 8 shows the Distribution portal entitlement configuration.

Figure 8. Distribution Portal Access Policy Entitlement
Figure 8. Distribution portal access policy entitlement

Creating approval workflows

OnDemand Inc. requires that all requests that gain access to a critical application go through an approval process. To approve access to the OnDemandDistributionRole and OnDemandSalesRole roles, an approval needs to be added by modifying the Person add and modify operations. This satisfies requirement R4.

Figure 9. Add an extension to facilitate the approval request
Figure 9. Add an extension to facilitate the approval request

The approveRolesByOwner(Person) extension is used to implement the approval process for both the add and modify operations as shown in Figure 10.

Figure 10. The approveRolesByOwner extension
Figure 10.: approverolesByOwner extension

User experience: Requesting a role assignment

TIM 5.0 introduces a new self-service console. This console allows users to perform a variety of self-service tasks. which includes allowing users to request access entitlements. In the case of OnDemand Inc., the company wants to allow users to request access to the sales role or the distribution role. OnDemand Inc. has setup roles for these resources, so that staff can request them as role access entitlements as shown in Figure 11.

Figure 11. User Judith Hall requests access to the sales portal
Figure 11. Judith Hall requests access to the sales portal

Approving the role assignment

When a user requests access to a role, the Person modify workflow is called causing an approval request to be generated. The target for this approval is the role owner. The role owner at OnDemand Inc. is Mike Stevens. When Mike logs into the self-service console, he receives an approval request to authorize Judith Hall access to the sales portal.

Figure 12. Mike Stevens receives an approval notification
Figure 12. Mike Stevens recieves an approval notification

When Mike Stevens has approved the role access entitlement, it will show up in Judith's list of accesses as shown in Figure 13.

Figure 13. Sales role access entitlement granted to Judith
Figure 13. A granted Sales role access entitlement

Judith is now able to access Sales portal page via WebSEAL. Figure 14 shows the main OnDemand Inc. home page. It has links to the sales and distribution Web pages.

Figure 14. OnDemand Inc. main portal page
Figure 14. OnDemand Inc. main page

Figure 15 shows the OnDemand Inc. sales page. This page is restricted to OnDemand Inc. sales staff. Judith can now access the sales page but she cannot access the distribution page.

Figure 15. OnDemand Inc. sales portal page
Figure 15. OnDemand Inc. sales page

Conclusion

By introducing the request-based role assignment feature, ITIM is now fully enabled for the request-based provisioning model. You are now able to implement combinations of the role-based and the request-based provisioning to better meet your business needs.


References

Resources

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. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. 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 Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), Security, Tivoli
ArticleID=314631
ArticleTitle=Request-based role assignment in Tivoli Identity Manager
publish-date=07082008