IBM DB2 Content Manager security model essentials

Keep your ECM data secure

IBM® DB2® Content Manager (CM) provides a flexible way of defining the security for your Enterprise Content Management (ECM) system. Depending on your business needs, you can design the security for your ECM system to be lenient or strict. CM provides various levels of security through authentication and authorization, and CM uses privilege sets and Access Control Lists (ACLs) to provide a stringent authorization mechanism. In this article, explore the methods for keeping your ECM data secure.


Naga Praveena Palasamudram (, Staff Software Engineer, IBM

Praveena Palasamudram's photoPraveena is a team lead working with India Software Lab, for Information Management team. She has 7 years of working experience in IBM. Her primary focus is DB2 Content Manager Library Server development and support. Currently she is working on providing L3 support and development of IBM FileNet Content Services. She is IBM certified solution designer for Content Manager. She is also certified IBM DB2 DBA.

Suma C. Shastry (, Staff Software Engineer, IBM, Software Group

Suma Shastry's photoSuma is a certified Solution Designer for IBM DB2 CM working as a team lead with India Software Lab, for Information Management team. She has 7 years of working experience in IBM. Her primary focus is FileNet IDM QA. She is certified FileNet IS Administrator, IBM DB2 DBA and Application Developer. She has published couple of articles in developerWorks.

Aruna Dadi (, Software Engineer, IBM

Aruna Dadi's photoAruna is a developer working with ISL, for Information Management team. Her primary focus is providing L3 support and development of IBM DB2 Content Manager Library Server. She is IBM certified DB2 Associate.

15 November 2007

Also available in Russian


IBM DB2 Content Management system is one of the widely used Enterprise Content Management products, used for managing both structured and unstructured information. It comes with a variety of products, each for a different purpose or functionality. More information about these products and their features can be found at the IBM DB2 Content Manager Information Center.

This article touches on the various aspects and concepts of CM security model. Take a look at various ways of authenticating to a CM system and various levels of authorization. With the help of examples, this article highlights privilege sets and Access Control Lists (ACLs) to be granted to CM entities like users, usergroups, itemtype, item, workflow, and so on. This article also discusses a business case scenario that illustrates a CM system with different levels of security for various CM entities.

CM security model

IBM DB2 CM has a flexible security model which lets the administrator decide on the kind of security for the ECM system. Depending on the business need, the ECM system could be designed to be lenient or strict. IBM DB2 CM provides various levels of security through authentication and authorization.

Figure 1. Security model
Security model

IBM DB2 CM supports three classes of users : OS level, CM level, and LDAP. However, the users need not worry as to how they are authenticated. CM uses privilege sets and ACLs to provide a stringent and granular authorization mechanism. It supports a flat security model, in which each document/item stored in the system has the same level of security defined. It also offers a more secured model in which each item or document stored has a different level of security. Privileges, privilege groups, privilege sets and ACLs form the basis of the authorization system of IBM DB2 CM and are discussed in further detail later in the article.


The users of a CM system can be broadly classified as:

  • Administrative users: Administrative users must be defined at the OS level. They log on to the CM system using their system password. The userid and password for these users are validated by underlying RDBMS (IBM DB2 or Oracle) of IBM DB2 CM. The administrative users are able to execute all the data modeling operations like itemtype creation, defining ACLs, and so on. More on CM data modeling can be found in the Resources section. IBM DB2 CM installation creates an administrative user. The default administrator id is ICMADMIN.
  • Non-administrative users: Non-administrative users are defined only in the CM system and are not OS users. The CM system authenticates these users and uses a shared database connection id to connect to the database. The default database connection id is ICMCONCT. However, administrators can also configure this id from the System Administration Client > Tools > Manage database connection id menu. Note: There can be only one connection id per library.

IBM DB2 CM also supports integration with LDAP directories. You can import the user directory list from the LDAP directory in to the CM system using a tool called the LDAP user import tool. Once these users are imported into the CM system, CM lets LDAP authenticate these users.

Apart from the above-mentioned authentication, CM system also supports single sign-on. You can enable this feature during the IBM DB2 CM installation. More on IBM DB2 CM single sign-on can be found in the IBM DB2 Content Manager Information Center.


CM uses privileges, privilege groups, privilege sets, and ACLs to authorize the users to perform specific operations on specific items. You can create these with CM System Administration Client.

Privileges and privilege groups

To access a CM system and perform certain CM functions, you need privileges. CM system provides users with nearly 100 predefined privileges. To manage them easily, CM provides the administrator a convenient way of grouping these privileges. Using a privilege group, the administrator can group a set of privileges based on various factors like roles performed by the users and functions used. One privilege can be part of more than one privilege group.

Privilege sets

IBM DB2 CM does not allow privileges to be assigned to the users or user groups directly. Instead, privilege sets are used for this purpose. A privilege set is a set of privileges. Users are assigned privilege sets and are validated to see if they have authorization to perform certain CM functions/operations.

Figure 2, below, depicts how a privilege set is formed making use of privileges and privilege groups. Privileges from multiple privilege groups can be part of a single privilege set.

Figure 2. Privilege Set
Privilege Set

You can select a particular privilege group on the left-hand pane to filter the privileges that you might want to add, so that only privileges that are part of that particular privilege group are displayed.

Privilege sets are used in three places:

  1. While creating a user, to provide the maximum privileges for a user: While creating a user, maximum privileges for a user needs to be defined. Either an existing privilege set is selected or a new one can be created. This is the maximum privilege a user has on any CM entity like itemtypes, items, ACLs, processes, worknodes, and so on. These privileges can be reduced when combined with ACL rules.
    Figure 3. Assigning privilege sets to a new user
    Assigning privilege sets to a new usert
  2. While creating an ACL:
    Figure 4. Usage of privilege sets while creating ACL
    Usage of privilege sets while creating ACL
  3. To assign to a domain, in case domains are enabled. This articles discusses domains later.

Access Control Lists (ACLs)

Access Control Lists define the level of access on a particular CM entity for users and user groups. These are used at runtime during create, read , update, or delete operations. ACL name does not have any effects without ACL rules in it. For example, when a user sends a request to add an item of a particular itemtype, depending on the ACL binding level, CM system checks the ACL and also the maximum privilege set for the user to see if he can add an item. CM also allows bypassing of the ACL check. This can be achieved by setting the "maximum privilege set" for a user to ItemSuperAccess privilege.

Predefined ACLs

IBM CM provides users with four different ACLs, which the administrator can use as is or modify:

  • SuperUserACL: This is an empty ACL created during installation. This is the default ACL for user groups.
  • NoAccessACL: This ACL prevents users to do any actions on an object. This is not used anywhere.
  • PublicReadACL: This allows all CM users to read the entities. This is only true when public access is enabled.
  • DocRouteACL: This is the doc routing ACL. By default, it does not contain any ACL rules. A user needs to add ACL rules to let the users perform the doc routing operations.

The ACL rule for the user overrides the ACL rule for the usergroup. In other words, if an ACL has two rules, one for the user and one for the usergroup that the user belongs to, then the latter will be discarded, and the ACL for the particular user is used. However, usergroup ICMPUBLIC is treated differently. If an ACL has a rule for a user and a rule for ICMPUBLIC, then both will be considered, and the user will have access if either of the rules is satisfied.

Example 1: ACL rule for a usergroup has a lower level of access, say read access, and the ACL for the user has higher level of access, say edit access. The effective access the user will get is edit. This scenario is true for ICMPUBLIC group also.

Example 2: Considering public access is enabled, if the ACL has a rule for the user with read access and ICMPUBLIC with edit access, then, if the operation requires edit access, the user will be granted edit access, if her max privilege set allows the operation.

Note: In the above example, the assumption is that the maximum privilege set assigned to the user has edit.

The effective access the user gains on a particular entity is the intersection of :

  • Maximum privilege sets assigned to the user, and
  • The ACLs that are defined on the entity

ACL bindings

ACL binding level defines where to pick the ACL from at runtime. These are defined while creating the item type. ACL can be bound at the following levels:

  • Item type level: All the items of a particular itemtype will have same ACL.
  • Item level

Public access

Public access is a way to enable CM to bypass ACL checking for each user or user group. If public access is enabled, all the users will be part of the ICMPUBLC user group, hence all rules for ICMPUBLIC will be activated. LS configuration dialog can be used to enable the public access. If public access is enabled, ICMPUBLIC takes priority on any other ACL. If it is not enabled, all the ACLs that specify ICMPUBLIC are ignored.

In short, privileges define which functions can be performed by the users, whereas ACLs define what level of access different users/usergroups have on a particular entity.

For example, if a user wants to edit the attributes of an item, then:

  • The user needs to have the edit access in his max privilege set
  • The ACL for the itemtype should have a rule that allows this user to edit the attributes of the item

Administrative domains

Administrative domains enable the CM administrative user, also called the super user, to share the administrative responsibilities with other administrators, each restricted to a particular part or domain. The super user defines the domain administrators. Each domain administrator can administer only his domains. Administrative domains can be enabled through the System Administration Client. Once domains are enabled, they cannot be dissolved. By default, when domains are enabled, three domains are created -- super domain, default domain, and public domain. These three domains cannot be dissolved.

A user/usergroup can be part of only one domain. There will be one superadmin and domain administrators for each domain. Privilege sets and Access Control Lists can be shared across domains (in other words, one privilege set or ACL can be part of multiple domains). This article does not get more in depth with Administrative domains, as it's out of scope of this article. Let's take a look at how to add users, privilege sets, and ACLs to an administrative domain:

Figure 5. Adding a user to a domain
Adding a user to a domain
Figure 6. Enable privilege sets to be part of multiple domains
Enable privilege sets to be part of multiple domains
Figure 7. Enable ACLs to be part of multiple domains
Enable ACLs to be part of multiple domains

Case study

Let's consider a project delivery system that involves various users with different roles and diverse sets of content. Let's consider a system that has the following user groups:

  1. Sales: Sales persons should be able to edit sales metrics and view/read product documentation. However, they shouldn't be able to view architecture/design documents, source code, approvals, or test results.
  2. Architecture: The architecture group does not need to know about the sales metrics and test results. However, persons in this group will be able to edit the architecture documents, functional specifications, and view the source code.
  3. Developers: Members of this group will create/update/delete the source code, functional specifications, and view the test results.
  4. Testers: Testers will be able to create/update/delete the testcases, test results, and view the product/builds, functional specifications, and product documentation.

To set up the above system, follow the steps outlined below. (This case study assumes that public access is not enabled.)

Table 1. Step 1
Create the required privileges and privilege sets
ReadSetRead, Query
EditSetRead, Create, Update, Delete, Select
CreateSetRead, Create, Select
UpdateRead, Update, Select
Table 2. Step 2a
Create the required users and user groups
DevD1, D2, D3
ArchitectA1, A2, D3
QAT1, T2
SalesS1, S2
Table 3. Step 2b
Assign max privilege set to the users
Users Maximum privilege to be assigned
Table 4. Step 3
Create ACLs
ACL NameUsers, PrivilegeSets
DevACLDev - EditSet
Architect & QA - ReadSet
Sales - NoAccessACL
CodeACLDev - EditSet
Architect - ReadSet
ArcACLArchitect - EditSet
Dev - ReadSet
D1 - EditSet
QA and Sales - NoAccessACL
TestACLQA - EditSet
Dev & Architect - ReadSet
Sales - NoAccessACL
SalesACLSales - EditSet
Dev, Architect QA - NoAccessACL


  1. Effective access gained by the user is the intersection of maximum privilege set of the user and the associated ACL.
  2. User ACL overrides the UserGroup ACL.
  3. If the user is part of more than one UserGroup, then the user gets the union of the ACLS for each usergroup.

Note: This case study also uses NoAccessACL, which is predefined by CM.

Table 5. Step 4
Create the Itemtypes with the associated ACLs
ItemType nameACLRemarks
ArchDocs ArcACL Itemtype to contain both the architecture and design documents
FunctionalSpecs DevACLContains functional specifications, which will be shared with QA to write the functional verification test suites
Code CodeACL Source code, which only the developers have access to
SalesDocs SalesACL Sales documents, which contain the customers lists, product level of customer, number of customers, products sold by each sales person in a quarter, and so on
Testcases TestACL Testcases, testsuites, test results, documents on how to run these testsuites, and so on

Based on the rules, Table 6 lists the accesses gained by each user:

Table 6. Effective gained access
ItemtypeGained accessExplanation
ArchDocsA1, A2, D3 - EditSet
D1 - EditSet
D2 - ReadSet
T1, T2, S1, S2 - NoAccess
As D3 is part of both Architect group and Dev group,
D3 gains Edit access (see rule 3).
As ArchACL has D1 with edit access, Dev group with read access,
D1 gains edit access (see rule 2).
FunctionalSpecsD1,D2, D3 - EditSet
A1, A2, T1, T2 - ReadSet
S1, S2 - NoAccess
Even though the usergroups Arch, QA, have a maximum privilege of
"EditSet", they gain only read access (see rule 1).
CodeD1, D2, D3 - EditSet
A1, A2 - ReadSet
T1, T2, S1, S2 - NoAccess
Since CodeACL doesn't contain any rule for QA and Sales,
they don't get any access.
SalesDocsS1, S2 - EditSet
A1, A2, D1, D2, D3, T1, T2 - NoAccess
(see rule 1)
TestCasesT1, T2 - EditSet
D1, D2, D3, A1, A2 - ReadSet
S1, S2 - NoAccess
(see rule 1)


The flowchart in Figure 8 summarizes how the hierarchy of authorization takes place while a user tries to create an item in the CM system.

Note: The following flow is valid when "Public Access" is enabled.

Figure 8. Flow chart
Flow chart

You are encouraged to read through various aspects of CM system by referring to Resources section.


We would like to thank Phong K Truong and Monica Ho, team leads of IBM DB2 CM Library Server team. We would also like thank all others who have provided their valuable suggestions and comments.



Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.



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 Information management on developerWorks

Zone=Information Management
ArticleTitle=IBM DB2 Content Manager security model essentials