EMC Documentum Education Services

Designing a Documentum Access Control Model

By Kristy Bueche, Technical Courseware Developer
August 18, 2009

Introduction
For many organizations, the ability to control access to sensitive content is one of the
most important features provided by EMC Documentum software. For a Documentum
application architect, designing the access control model can be one of the more
challenging design tasks.
Requirements for access control vary widely among different organizations and across
applications within an organization. There is no one-size-fits-all design solution. The
challenge for an architect is to ensure that an organization’s requirements for access
control are met while also ensuring that the security model does not slow down query
performance or impose other negative consequences on the application.
This paper describes some best practices and some known issues with certain access
control models but most importantly it presents an approach for evaluating the
“goodness” of any access control model.

The Basics of Access Control with Documentum

EMC Documentum’s access control architecture is based on ACLs (access control lists)
but has evolved and expanded over time to satisfy many diverse security requirements.
I’m assuming that the reader is already familiar with the access control features provided
by Documentum. The following are good resources for learning the basics of
Documentum’s security features:
Documentation: The Security Services chapter of the EMC Documentum Content Server
Fundamentals guide
Training: Technical Fundamentals of Documentum
Blogs:
http://www.bluefishgroup.com/library/1999/what-are-access-control-lists/
http://ajithp.com/2007/11/01/more-on-documentum-security/.
In addition to basic ACLs, features such as dynamic groups, application access control,
folder security, etc., as well as add-on products such as Trusted Content Services (TCS),
and Information Rights Manager (IRM) allow for even more sophisticated approaches to
controlling access to content. More on Documentum’s rich set of security features that go
beyond ACLs is covered later in this document. However, this document is primarily
concerned with validation of a standard ACL based access control model.

Designing a Documentum Access Control Model 1 of 10

EMC Documentum Education Services

What is an access control model?

The term, access control model, refers to the configuration of users, groups, roles, and
ACLs (aka Permission Sets) used to control access to documents. Just to crystallize the
concept of an access control model, here are a few examples of different models that may
be used in an application:
Example 1: Few ACLs – Each ACL has Large Content Coverage
In this model there are a few well-known ACLs that are reused across large numbers of
documents.

acl

accessors
(i.e. users, groups, roles)

documents

If many documents are assigned the same ACL, then the ACL has a
large content coverage.

Figure 1 - Example 1: Each ACL has Large Content Coverage

Example 2: Individualized ACLs – Each ACL Is Applied to Few Documents

In this model, many individual ACLs are used. Each ACL is applied to very few
documents resulting in the existence of many ACLs. The most extreme case of this model
is when custom ACLs are exclusively used so every object has its own ACL. This usually
occurs when security settings are programmatically applied to documents. It can also
occur when permission set templates are used.

acls

accessors
(i.e. users, groups, roles)

documents

Many individual ACL’s are generated for documents

Figure 2 - Example 2: Individualized ACLs, Each ACL Applied to Few Documents

Designing a Documentum Access Control Model 2 of 10

EMC Documentum Education Services

Example 3: User Belongs to Many Groups or Roles

In this model a unique group or role is associated with each “set” of documents. Certain
users require access to all “sets”. Therefore these users are placed in all groups. This can
lead to a single user belonging to thousands of groups.

User belonging to
many groups or roles

accessors acls document

Figure 3 - Example 3: User Belongs to Many Groups or Roles

These are just a few examples. The variations on configurations for relating users,
groups, roles, ACLs, and documents could go on and on. The important thing to be
aware of is that some access control models work better than others. For example, certain
models can contribute to slow application performance, some won’t scale well as the
number of users or documents becomes large, and some may be difficult to administer.
If the access control model that you have designed introduces problems in your
application, there are usually small changes that you can make, either in the model or the
application, to avoid the problem without compromising on the ability of the application
to meet its access control requirements. Proactively evaluating and testing a model to
identify potential issues during the design phase and making necessary changes rather
than finding out post implementation or even worse, post-deployment, can save a lot of
trouble in the long run.
So how do you know if the access control model that you are designing for your
application is a good one?

Evaluation Criteria for an Access Control Model

In assessing the “goodness” of your model, consider the following factors against which
to measure your design:
1. Does the access control model negatively affect application performance?

Designing a Documentum Access Control Model 3 of 10

EMC Documentum Education Services

2. Is the access control model easy to administer?

3. Does the access control model enable the organization to meet its security
requirements?
The following sections explore each of these factors. In addition, some known best
practices for implementing access control models are noted with a .

Impact on Application Performance

The access control model can be considered an extension of an application’s data model.
After all, users, groups, roles, and ACLs are just objects in the repository. Users, groups,
and roles are related to ACLs through repeating attributes on the dm_acl object. ACLs
are related to documents through the acl_name and acl_domain attributes of
dm_sysobject. The Content Server issues join and other queries involving these security-
related objects and sysobjects to prevent unauthorized operations on content.
As described in my previous post: Data Modeling with Documentum, the underlying
SQL queries generated by an application are largely responsible for the operation
response times achieved by the application. The access control model will change those
SQL queries. Here’s an example:
Imagine that a user with super user privilege logs into an application and the application
issues the following DQL statement:
select r_object_id, object_name, loan_amount from test_regional_loan_1
where date_received = DATE('3/29/2008 12:00:00') and
customer_number='00000' and region='CA'

Because the user is a super user, no access control filtering is applied. The following SQL
query will be sent to the RDBMS:
Note: The actual SQL shown here is not too interesting. It is not useful to scrutinize or
dissect the SQL statement. This example is only used to illustrate the important take away
that the access control model influences application performance by affecting the SQL
generated by the Content Server and sent to the RDBMS.
select all test_regional_loan_1.r_object_id,
test_regional_loan_1.object_name, test_regional_loan_1.loan_amount from
test_regional_loan_1_sp test_regional_loan_1 where
((test_regional_loan_1.date_received= to_date('29/03/2008 19:0:0',
'DD/MM/YYYY HH24:MI:SS')) and
(test_regional_loan_1.customer_number='00000') and
(test_regional_loan_1.region='CA')) and
(test_regional_loan_1.i_has_folder = 1 and
test_regional_loan_1.i_is_deleted = 0)

If another user logs in, who does NOT have super user privilege and the application
issues that same DQL statement, the resulting SQL query will have security filtering
applied. The SQL statement will look more like the following:
Note: Although this query is much longer, the number of conditions does not
automatically mean that the query will run slower. The Content Server uses highly
optimized queries for security filtering.

Designing a Documentum Access Control Model 4 of 10

EMC Documentum Education Services

select all test_regional_loan_1.r_object_id,

test_regional_loan_1.object_name, test_regional_loan_1.loan_amount from
test_regional_loan_1_sp test_regional_loan_1 where
((test_regional_loan_1.date_received= to_date('29/03/2008 19:0:0',
'DD/MM/YYYY HH24:MI:SS')) and
(test_regional_loan_1.customer_number='00000') and
(test_regional_loan_1.region='CA')) and
(test_regional_loan_1.i_has_folder = 1 and
test_regional_loan_1.i_is_deleted = 0) and ( (
test_regional_loan_1.owner_name in ('studenta','dm_world','docu')) or
(exists (select 1 from dm_acl_s ACL_S0, dm_acl_r ACL_R where
ACL_S0.r_object_id = ACL_R.r_object_id and
test_regional_loan_1.acl_domain = ACL_S0.owner_name and
test_regional_loan_1.acl_name = ACL_S0.object_name and
((ACL_R.r_accessor_name in ('studenta','dm_world') or (ACL_R.r_is_group
= 1 and (ACL_R.r_accessor_name in ('studenta','dm_world','docu')))) and
((ACL_R.r_permit_type = 0 or ACL_R.r_permit_type is null) and
(((ACL_R.r_accessor_permit >= 2) and ((ACL_S0.i_has_access_restrictions
= 0 or ACL_S0.i_has_access_restrictions is null) or (not exists (select
1 from dm_acl_r ACL_R2 where ACL_R2.r_object_id = ACL_S0.r_object_id
and ACL_R2.r_permit_type = 3 and (ACL_R2.r_accessor_name in
('studenta','dm_world','docu')) and (ACL_R2.r_accessor_permit >= 1 and
ACL_R2.r_accessor_permit <= 2))))))) and ((ACL_S0.i_has_required_groups
= 0 or ACL_S0.i_has_required_groups is null) or (not exists (select 1
from dm_acl_r ACL_R2 where ACL_R2.r_object_id = ACL_S0.r_object_id and
ACL_R2.r_permit_type = 6 and (ACL_R2.r_accessor_name not in
('studenta','dm_world','docu'))))) and
((ACL_S0.i_has_required_group_set = 0 or
ACL_S0.i_has_required_group_set is null) or (exists (select 1 from
dm_acl_r ACL_R2 where ACL_R2.r_object_id = ACL_S0.r_object_id and
ACL_R2.r_permit_type = 7 and (ACL_R2.r_accessor_name in
('studenta','dm_world','docu')))))))))

Again, the important take away is that the access control model can affect RDBMS
queries generated by the Content Server and potentially influence application response
times. Therefore, performance testing of an application and validation of the data model,
as described in Data Modeling with Documentum, should include a realistic simulation of
the access control model.
When evaluating performance consider how the access control model affects both 1)
single object fetch and 2) response time for queries.
Performance problems most often arise for one of two types of users so make sure to
test both of these cases:
1. Users with wide access to documents.
2. Users with extremely limited access to documents
We’ll consider the first case: users with wide access to documents. If a user belongs to
thousands of groups, as described in Example 3 above, query performance and other
application response times for that user will degrade in most versions of Documentum
software. Avoid this situation by following this best practice:
Create a group for users that should have wide access to documents. Add that group
as an accessor to ACLs rather than putting a user in thousands of groups in order to
give the user wide access.

Designing a Documentum Access Control Model 5 of 10

EMC Documentum Education Services

Now consider the second case: users with extremely limited access to documents. An
example of where performance issues may arise in this second case, is when fulltext
searches return large result sets at the fulltext server and the application relies on security
filtering at the RDBMS to narrow the result set. Often, it would be a straightforward
customization to the application to add more selective criteria to fulltext queries. For
example, if documents are project related and users can only see documents in projects
they are working on, both the user and documents can be tagged with metadata to
indicate their associated projects. This metadata can then be used by the application to
create a more selective fulltext query. For example, consider the following fulltext query
that might be issued from an insurance claims processing application:
SELECT r_object_id, object_name FROM acme_insurance_claim SEARCH
DOCUMENT CONTAINS ‘police report’

This query could likely return tens or hundreds of thousands of documents resulting in a
huge result set that must be processed by the Content Server to apply security filtering. If
a user is only allowed to see documents related to open claims originating in his branch
office then the application can be implemented to change the query as follows:
SELECT r_object_id, object_name FROM acme_insurance_claim SEARCH
DOCUMENT CONTAINS ‘police report’ and claim_status = ‘open’ and
branch_office = ‘Pleasanton’

Now this query is highly selective at the fulltext server and a very small result set will be
returned by the fulltext server to the Content Server for security filtering. This small
change in the query will result in users experiencing much better response times. Use the
following best practice to mitigate the risk of slow fulltext query performance for users
with highly restricted access to content:
In repositories in which access to documents is highly restricted for certain users,
customize applications as needed to include conditions on fulltext queries to make
them more selective at the fulltext server.
In this case, you are not changing the access control model but customizing the
application to work well with a given model.

Ease of Administration
As users, groups, roles, and access requirements change over time, the relevant security
objects will need to be updated. Consider the impact your access control model has on
administrative operations that must occur in response to inevitable events such as the
following:
• A user’s name changes as a result of marriage or some other reason
• A user leaves the company and must be denied access to documents
• A new user must be granted access rights to documents
• A user’s access rights change
• Access rights on documents change

Designing a Documentum Access Control Model 6 of 10

EMC Documentum Education Services

Here are some examples of access control models that can make administration
cumbersome:
Large numbers of individualized ACLs
A model, such as Example 2 above, in which large numbers of per document custom
ACLs are used can be harder to administer. When access rights change, consider how
many ACL objects the administrator will need to update. Using DQL to modify ACLs
can be quicker than using a GUI application such as DA, but also requires that the
administrator have more Documentum expertise.
It’s generally better to reuse existing ACLs rather than write applications that result
in a proliferation of custom ACLs. Be aware that using permission set templates as
well as using the grant APIs (i.e. IDfSysObject grant and grantPermit)
will result in a custom ACL being created and assigned to a document. Use the
useacl API (i.e IDfSysObject useACL) to reuse existing ACLs.
Interestingly, in most cases, ACL proliferation is more of an administration issue rather
than a performance issue. Having millions of ACLs in a repository does not normally
affect single object fetch nor query response times. In the case of single object fetch, the
Content Server is only dealing with a single ACL, the one that is assigned to the object.
In the case of querying for a result set, ACLs are not generally a selective criteria and
consequently the number of ACLs don’t impact the query processing. However, as
previously mentioned, the number of groups a user belongs to will affect query response
times if the number of groups is extremely large.
Large numbers of accessors per ACL
A model that has large numbers of accessors per ACL can make it more difficult to
update the ACL. Accessors are stored as repeating attributes. When you insert or delete
attributes in a repeating list, many values in the list may be moved within the RDBMS,
causing the save operation on the ACL to be slow. In addition, the DA and Webtop user
interfaces for modifying ACLs do not accommodate a large number of accessors very
well.
Whenever possible, create groups or roles containing users with the same access
rights rather than placing individual users as accessors, in order to reduce the
number of accessors on each ACL.

Meets Security Requirements

There are cases where ACLs alone cannot accommodate an organization’s access control
requirements. Here are a few examples of additional features and products to use to help
meet access control requirements:
- IRM (Information Rights Manager): Enables configuration and enforcement of
security policies on documents that reside outside of a Documentum repository
- Extended permissions: Grants specific functions without automatically granting all
lower level permissions. For example delete_object extended permission gives the

Designing a Documentum Access Control Model 7 of 10

EMC Documentum Education Services

permission to delete an object without necessarily allowing the right to read, write,
version, etc.
- Dynamic groups: Applications can, at run time, move users in and out of groups.
This is useful, among other things, for modeling security labels such as Classified,
Top Secret, etc.
- Application access control: Helps prevent unauthorized access to a repository by a
client application
- TCS (Trusted Content Services): Provides numerous additional security features
such as the following:
o Required Groups: Accessor must be a member of specified groups to access
an object, for example: Only people with “Top Secret” clearance AND “US
Citizens” can access documents marked as “Top Secret”
o Required Group Sets: Accessor must be a member of at least one of the
listed groups to access an item, for example: Only people “in US”OR “in
Japan” can access documents marked as “US-Japan Confidential”
o Access Restrictions: Accessor is explicitly denied access despite being a
member of a group that has been given access, for example: A person can
only have “Read” access for a given document even if he belongs to a group
that is granted higher access to the same document
o Ability to encrypt stored content
o Electronic signatures
o Digital shredding
A detailed explanation of these and other features is out of scope for this paper. The focus
of this paper is not to fully explain all of the security capabilities of Documentum. Rather
it is to raise awareness about the impact of the access control model. But it is important to
mention that certain requirements cannot be shoe-horned into the ACL model and other
security features and products should be used in those cases.
If you determine that ACLs alone will not suffice, learn about the many other ways to
control access using Documentum security features and add-on products before
trying to customize in order to implement a necessary security feature..

Risk Evaluation
I’ve listed a few best practices for designing an application control model. But not all
“gotchas” are known and the variation on models is so great that they will never all be
known. The best way to determine if the access control model that you have designed
will perform well, scale, be easy to administer, and meet security requirements is to test it
during the design phase for your application.
Here is a three-step process for validating the access control model:
1. Identify boundaries

Designing a Documentum Access Control Model 8 of 10

EMC Documentum Education Services

Every access control model will push certain boundaries as the application gets used and
the repository scales up in terms of the number of users or objects. Identify what
boundaries your planned model is pushing. For example:
- Example 2, described above, in which each document gets a custom ACL will
eventually result in potentially millions or even billions of ACLs in the repository
- Example 3, described above, in which a new group or role is created for each “set” of
documents can result in a user being placed in thousands (or more) groups.
- A model may result in tens of thousands (or more) accessors per ACL
- A model may result in deeply nested groups or roles
- A model may result in tens of thousands (or more) members per group
- Etc.
You get the idea. Identify the boundaries that your access control model will be pushing
over time as the number of users and documents grows large.
2. Load a test repository
Once you’ve identified the boundaries that you need to test, load a repository with objects
to create a realistic simulation of the access control model as it will exist in a production
repository over time. Make sure that the loaded repository is pushing the extreme limit of
the boundaries that you’ve identified.
To create your test repository, you can do one of the following: 1) write a custom
application to load objects, or 2) use the DmBasic Object Loader Utility
(http://developer-content.emc.com/developer/tippage.htm#0900c35580265dbd) modified
as needed, or 3) use the SecurityTestDriver sample program used in the Object Security
– Access Control lab of the Architecting EMC Documentum Applications training course.
The SecurityTestDriver sample program allows you to configure and generate different
types of security models in a repository. In the lab, students create and test several access
control models in order to determine risks, limitations, and issues with various models.
As with all EMC Documentum training courses, lab files are available for students to
download (http://mylearn.documentum.com/labfiles/arcapp-0509.zip),
The C:\Student\Architecting Applications\Lab06\SecurityTestDriver.zip file is an
archived Composer project. Once you import the archived project into Composer, you
can use Composer to configure and run the program to create the desired access control
model in a repository.
The test driver program is a java application. It reads an XML configuration file that
describes different quantities and characteristics of dm_user, dm_role, dm_acl, and
dm_document objects. When run, the program reads the configuration and then creates
the described objects in the repository.
3. Test user and administrative operations
Finally, devise a set of tests that allow you to determine the following about your access
control model:

Designing a Documentum Access Control Model 9 of 10

EMC Documentum Education Services

• How will it scale to large numbers of users?

• How will it scale to large numbers of documents?
• How will it be administered?
• How will it affect performance of single object fetch for each type of user?
• How will it affect query performance for each type of user?
• Does the model meet the organization’s requirements for controlling access to
documents?
Determine the most important operations that users and administrators will need to
perform and test each of these operations in order to identify risks, issues, or limitations
with the design of the access control model. Make sure to test the model for different
types of users especially those who have wide access and those with very restricted
access.

Conclusion
Certain characteristics of an access control model are known to introduce risks to an
application such as slower query or fetch performance or difficulty in administration.
These risks can often be easily mitigated with small changes to the security model or to
the application. But there are so many different ways to design an access control model
that there is no comprehensive set of best practices that encompass all possible designs.
The best way to determine the goodness of an access control model is to 1) identify the
boundaries that the access control model will be pushing 2) load a repository with objects
to create a realistic simulation of the access control model as it will exist in a production
repository over time 3) determine the most important operations that users and
administrators will need to perform and test each of these operations in the test
repository.
The Object Security – Access Control module of the Architecting EMC Documentum
Application course includes a lab in which student use this approach to test several
security models to identify risks, issues, or limitations with various designs and identify
ways to mitigate those risks.

To Learn More
To find out more about EMC training course offerings for the EMC Documentum
platform and products, visit EMC MyLearn at http://mylearn.emc.com.

Designing a Documentum Access Control Model 10 of 10