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
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.
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
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:
- 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
- While creating an ACL:
Figure 4. Usage of privilege sets while creating ACL
- 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.
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 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 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 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
Figure 6. Enable privilege sets to be part of multiple domains
Figure 7. Enable ACLs to be part of multiple domains
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:
- 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.
- 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.
- Developers: Members of this group will create/update/delete the source code, functional specifications, and view the test results.
- 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
|EditSet||Read, Create, Update, Delete, Select|
|CreateSet||Read, Create, Select|
|Update||Read, Update, Select|
Table 2. Step 2a
|Dev||D1, D2, D3|
|Architect||A1, A2, D3|
Table 3. Step 2b
|Users||Maximum privilege to be assigned|
Table 4. Step 3
|ACL Name||Users, PrivilegeSets|
|DevACL||Dev - EditSet|
Architect & QA - ReadSet
Sales - NoAccessACL
|CodeACL||Dev - EditSet|
Architect - ReadSet
|ArcACL||Architect - EditSet|
Dev - ReadSet
D1 - EditSet
QA and Sales - NoAccessACL
|TestACL||QA - EditSet|
Dev & Architect - ReadSet
Sales - NoAccessACL
|SalesACL||Sales - EditSet |
Dev, Architect QA - NoAccessACL
- Effective access gained by the user is the intersection of maximum privilege set of the user and the associated ACL.
- User ACL overrides the UserGroup ACL.
- 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
|ArchDocs||ArcACL||Itemtype to contain both the architecture and design documents|
|FunctionalSpecs||DevACL||Contains 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
|ArchDocs||A1, 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).
|FunctionalSpecs||D1,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).
|Code||D1, 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.
|SalesDocs||S1, S2 - EditSet|
A1, A2, D1, D2, D3, T1, T2 - NoAccess
|(see rule 1)|
|TestCases||T1, 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
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.
- IBM DB2 Content Manager Information Center: Access the information that you need for IBM DB2 Content Manager.
- developerWorks Enterprise Content Management page: Find more developer articles and tutorials on IBM DB2 Content Manager and other IBM Enterprise Content Management products.
- developerWorks Information Management zone: Learn more about Information Management. Find technical documentation, how-to articles, education, downloads, product information, and more.
- Stay current with developerWorks technical events and webcasts.
- Technology bookstore: Browse for books on these and other technical topics.
Get products and technologies
- Build your next development project with IBM trial software, available for download directly from developerWorks.
- Participate in developerWorks blogs and get involved in the developerWorks community.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.