Choosing a Model for IBM Content Manager OnDemand System Administration

Document options Document options requiring JavaScript are not displayed Learn and share! Exchange know-how with your peers -- try our new Pass It Along beta app Rate this page Help us improve this content

Level: Introductory

Debbie Wagner, Software Engineer, IBM's Content Manager OnDemand for Multiplatforms

25 Jan 2002

IBM Content Manager OnDemand allows companies to manage large quantities of printed output, such as reports, invoices, or statements. Debbie Wagner, a CM OnDemand software engineer, describes recent changes in OnDemand that give greater flexibility in managing and securing these important assets.

© 2002 International Business Machines Corporation. All rights reserved.

Introduction

IBM Content Manager OnDemand is an automated archival and retrieval system that can store printed output such as reports, statements, invoices, and image documents. The printed output is processed and stored onto various types of storage volumes including hard disks, optical platters, and tapes. Index values are extracted from the printed output and stored in a relational database. After the printed output and index values are stored, you can use any of the OnDemand client programs to retrieve documents. IBM DB2 ® Universal Database ^TM (DB2 UDB) is included with OnDemand and serves as its database manager. Tivoli ® Storage Manager (TSM) is also included and serves as the archive storage manager.

A typical use for OnDemand is the storage and retrieval of monthly statements such as credit card statements. Each month a credit card company generates millions of credit card statements. The statements are processed and stored in OnDemand. In the next several months after the statements have been sent, a customer may have questions about a transaction that appears on his or her statement. With OnDemand, a customer service representative can retrieve the statement in question within seconds, view an exact copy of the statement received by the customer, and assist the customer in a timely manner.

Applications, application groups, folders, storage sets, and printers are the objects that represent how OnDemand stores, manages, retrieves, views, and prints reports and index data. You can control and limit access to the reports and index data by defining users and groups and giving them the level of authority that is required to meet the data security strategy of an organization. The object definitions are stored in the relational database in tables that are separate from the index data and are accessible through an administrative client program.

OnDemand provides the ability to centralize or decentralize the administration of the system. A centralized environment means that one type of user, a system administrator, controls the creation and access to all of the objects defined on the system. A decentralized environment, on the other hand, means that the tasks of the system administrator are divided and assigned to other users. The responsibilities of the other users may vary from user administration, group administration, application group administration, folder administration, or any combination of the administrative tasks.

Important: You should decide whether you want a centralized or decentralized environment before objects are added to the system. Although the decision is reversible, the amount of work required to change from one type of administration to the other can be significant if a large number of objects have already been added. This article describes how system administration works in OnDemand with special emphasis on decentralizing the administration of the system. I also describe two specific models for decentralizing the administration of the system: the Object Type model and the Object Owner model.

Back to top

Background for existing OnDemand users

From the first release of OnDemand, centralized system administration and limited decentralized system administration was supported. Support for the Object Type model was enabled by two user types: User Administrator and Application Group/Folder Administrator. In version 2.2.1.6 of OnDemand, the permission levels of Create Users, Create Groups, Create Application Groups, and Create Folder were added. The permission levels provided the function to support the Object Owner model described in this article, except that users and groups were visible to all of the users on the OnDemand system.

In version 2.2.1.10, a change was made to support the full Object Owner model. A ramification of this change is that users and groups are no longer visible in a list, such as a permission list, unless the user of the administrative client program has been given permission to see the user or group or has created the user or group. This change was crucial to be able to maintain data and user isolation on the same system.

Back to top

The basics

In general, users of an OnDemand system fall into four categories: an end user, a report administrator, a user administrator, and a system administrator.

• End User
  
  An end user logs on to an OnDemand server using a Windows Client program and submits queries to retrieve documents for viewing.
  
  
• Report Administrator
  
  A report administrator is responsible for determining what information will be extracted from the reports and saved as indexes, how the data will be loaded, stored, and maintained in OnDemand, and how the search criteria is presented to the end user. This information is saved in OnDemand in the following places: an application, an application group, and a folder.
  
  A report administrator is also responsible for determining which end users have access to the report data that has been loaded.
  
  
• User Administrator
  
  A user administrator is limited to adding end users to the system or adding other user administrators.
  
  
• System Administrator
  
  A system administrator has the highest level of authority on the system and is primarily responsible for giving other users permission to perform various tasks and functions. A system administrator is also responsible for defining groups, system printers, and storage sets which define the archival policies for the data.

With the user categories in mind and the tasks that must be performed by the various users, now you must decide whether system administration should be centralized or decentralized. In other words, is it required or necessary for one user to control access to the OnDemand system, or is it required or necessary to divide the administrative tasks between several users to control access to the OnDemand system or to spread the workload? When OnDemand is installed, a system administrator user is automatically added. In a centralized environment, this user, called "admin", is used to perform all of the administrative tasks such as adding end users, creating report definitions, loading data, providing report access to end users, etc. And, unless other administrator users are added to the system, the "admin" user is the only user that can perform these tasks.

It seems that being the sole administrator for OnDemand could be a lot of work. So, when is it appropriate to consider the centralized environment? Centralized system administration works well in smaller installations of OnDemand, in which "smaller" means that there is a small number of users and reports defined to the system. A centralized environment may also be best suited to an environment where resources are limited and only one person is available for system administrative tasks. System administration can also be centralized but controlled by more than one user; each user is a system administrator and can perform all of the system administrative tasks.

Back to top

Decentralized system administration

With the increasing need to provide more protection and privacy for computer data, a more sophisticated security strategy is necessary for many companies. OnDemand enables this strategy by allowing flexible decentralized system administration. Because of the various OnDemand user types and authority levels, there are many ways to decentralize the administration of the system; however, for most environments, the requirement to control access to specific data by individuals (or organizations) or to control access to specific objects of the OnDemand system is what determines how system administration is decentralized. Two models are described here

• Object Type model
• Object Owner model

Object type model

Figure 1 shows the Object Type model. The Object Type model provides the ability to control access to specific objects of the OnDemand system. For example, all of the reports that are defined to the system are created and maintained by a report administrator. All of the users and groups of users that are defined to the system are created and maintained by a user administrator.

In some environments, it is necessary to divide the administrative tasks based on skill level, security requirements, or related tasks. The Object Type model is the appropriate solution for this environment. Creating and maintaining report data requires a different set of skills than creating and maintaining users and groups of users. The number of users required to learn the skills of a report administrator can be limited to a small number of users. Another reason for using the Object Type model is when administrative tasks are performed by one user or a group of users, whether those tasks are for OnDemand or for other systems. The task of adding and maintaining users can also be kept separate from creating and maintaining reports to provide additional security for the data.

Implementing an object type model

In the Object Type model, the system administrator defines two new users.

• The report administrator, who is defined to OnDemand by adding a user with a user type of "application group/folder administrator"
• The user administrator, who is defined to OnDemand by adding a user with a user type of "user administrator with Create Groups authority."

The report administrator determines what information will be extracted from the reports and saved as indexes, how the data will be loaded, stored, and maintained in OnDemand, and how the search criteria is presented to the end user. This information is saved in OnDemand in an application, application group, and a folder.

A report administrator also determines which end users have access to the report data that has been loaded. The recommended and simplest way to do this is to give access to a group of end users rather than to individual end users. When another end user needs access to the report data, no additional work is required by the report administrator. When an end user is added to the group, the end user automatically gets access to all of the reports that are accessible to the group.

The user administrator is responsible for adding end users to the system and for creating groups of end users that need access to the same report data. The user administrator must also add the report administrator to any groups that require access to the report data. As a group member, the report administrator can see the group in the permissions list for the application groups and folders and can grant access to the group. This step is necessary because a report administrator does not have access to end users or groups and would not otherwise see them in the permissions list. Table 1 shows the administrative users and the tasks assigned to those users.

Table 1. Adminstrator roles in the Object Type model

Object owner model

Figure 2 shows the Object Owner model. The Object Owner model provides the ability to control access to specific reports by a limited group of users. The reports and users are created and maintained on the system by an administrator for that group of users. Other reports and users exist on the system and are maintained by different administrators. Each group of reports and users are independent of the other and are not accessible to any other group.

Companies that provide services such as billing, accounting, payroll, statement processing and printing to other companies need to keep the data from each company private and secure. In other words, customer service representatives or administrators from one company should not have access to data from other companies even though the data is maintained in one OnDemand system. The Object Owner model is the appropriate solution for this type of environment. The data for each company and the users that require access to the data are created and maintained by an administrator for each company.

Implementing an object owner model

In the Object Owner model, report data from several different sources resides on one OnDemand system. Each logical grouping of data is accessible by a distinct and unique set of users. For each logical grouping of data, the system administrator defines two new users:

• The user administrator, who is defined to OnDemand as a user with a user type of "user with Create Users and Create Groups authority". By defining the user administrator in this way, the user administrator has authority to only those end users and groups that he or she creates.
  
  
• The report administrator, who is defined to OnDemand as a user with a user type of "user with Create Application Groups and Create Folders authority." The report administrator only has authority to the applications, application groups, and folders he or she creates.

The system administrator must also give the user administrator access to the report administrator. Otherwise, the user administrator will not be able to add the report administrator to any groups he or she creates. Again, this is because the user administrator did not create the report administrator and has access to only those users he or she creates.

The responsibilities of the user administrator and report administrator in both models are the same. The difference is that in the Object Type model, the administrators have authority over all of the users or reports on the system and in the Object Owner model, the administrators have authority over only those users or reports they create. Table 2 shows the administrative users and the tasks assigned to the users.

Table 2. Administrator Roles in the Object Owner Model

Variations

There can be many different variations of the two models that have been described. For example, in the Object Owner model, rather than defining the report administrator as a user that defines both the application groups and folders, the function of the report administrator can be given to two users -- one user creates application groups and the other user creates folders. Choosing the right model or variation is an important decision, so make it early in the planning process. Changing to a different model later is not impossible but may require additional work if there are a large number of objects defined on the system.

Back to top

Recommendations

Here are some general guidelines for deciding whether to centralize or decentralize system administration and, if decentralization is selected, which model to use.

Back to top

Hints and tips

• To allow multiple users to administer the same groups, create a group of users and make that group the group owner for any groups that need to be administered by multiple users.
  
  
• The Create Groups authority is most effectively used if it is combined with the Create Users authority or added to a user with a user type of user administrator. Because the purpose of a group is to give a set of users the same permissions, it is not very useful if the user that creates the group does not have access to any users.
  
  
• Access to report data should be given to a group of end users rather than individual end users. When a new end user needs access to the report data, add the end user to the appropriate group.
  
  
• To allow the report administrator to see groups in the permissions list of application groups and folders, always add the report administrator to the groups that require access.

Windows is a registered trademark of Microsoft Corporation in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

IBM copyright and trademark information

About the author

		Debbie Wagner is a Software Engineer for IBM's Content Manager OnDemand for Multiplatforms.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top