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.
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.
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
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
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.
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.
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.
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.
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
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.
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
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 6 shows the 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 8 shows the Distribution portal entitlement configuration.
Figure 8. Distribution Portal Access Policy Entitlement
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
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
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
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
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
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 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
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.
- IBM Tivoli Identity Manager Online Help and Information Center
- Identity Manager Extensions documentation shipped with ITIM (<ITIM install directory>/extensions/doc)
- 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.
.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
