Documentum Group Expansion (Aspire 2)
For Information on Aspire 3.1 Click Here
Access Control Lists (ACLs) are Documentum's method of restricting access to important documents. ACLs control Documentum's security layer:
- You can assign seven different levels of access to your documents.
- You can assign access to individual users or to groups of users.
- Users can create their own private ACLs that only they can use.
- System Admins can create System-Wide ACLs that can be used by everyone.
- Extended Permissions let you tweak what a user can do to an object.
- Every sysobject in a docbase has an ACL assigned to it.
An ACL contains information about which users and groups have access to the document, and what level of access each has. When a user attempts to access an object, the Documentum Server looks in the ACL to determine which groups have access. It then looks in these groups to determine if the user is in any of the groups. It determines the user's access level by awarding the user the highest level of access taking into account all the groups that the user is a member of.
Note: Even if you explicitly assign NONE access to a user, if they are also in a group that has READ access, the user will have READ access to the object.
Levels of access available
NONE (1): A user with NONE access will never know that the document exists. They won't see it in a folder, and if they query for it, it will not be returned in the result list.
BROWSE (2): A user with BROWSE access will be able to see the attributes of a document, but can not view the content. The user will see the document within the folder in which it lives, and the user can query for it.
READ (3): A user with READ access can view the attributes and content of a document, but can not annotate it, version it or edit it.
RELATE (4): A user with RELATE access can view the attributes and content and can annotate the content.
VERSION (5): A user with VERSION access can read, annotate, and create new versions of a document, but can not overwrite the current version of the document. If a user with VERSION access wants to modify the attributes of a document, he must check it out, modify the attributes, then check it in.
WRITE (6): A user with WRITE access can read, annotate, version, and overwrite the current document, but can not delete it. A user with WRITE access can modify the attributes of a document without checking it out.
DELETE (7): A user with DELETE permission can do all these things, plus delete the document. DELETE permission is the highest level of permission that a user can have on a document.
These permits are cumulative. e.g. If you have READ permit, you can also browse. If you have WRITE permit, then you can also version, relate, read and browse.
If the user:
- is dm_owner -> has access to the document no matter what.
- is not in all the required_groups -> has no access.
- is not in at least one of the required_group_set -> has no access.
- is on the deny list -> has no access.
- is on the dm_world -> has access.
- is on the allow list -> has access.
Group expansion for our connector
Unlike the other connectors, ACL IDs are used as group names for Documentum's group expansion. The reason behind this is because it provides numerous additional security features such as the following:
- dm_owner: Permits that apply over the file owner.
- dm_world: Permits that apply over all other users but the owner.
- 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”.
- 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”.
- 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.
We are not able to validate these permissions during the crawl without doing group expansion, which is why we've indexed each file's ACL ID as a group name. And during group expansion, all ACLs are downloaded and all groups in which the user belongs are fetched. Each ACL is checked to make sure the user has permission to see the file.
The component performs group expansion in the following way:
BROWSE is the minimum permission the user must possess to have access to a file.
This component is based on the Simple Group Expansion
|host||string||The Documentum server docbroker name to connect to.|
|port||int||1489||The Documentum server's docbroker port.|
|docBase||string||The Documentum docbase to connect to.|
|dfcPropsFilePath||string||The path to the Documentum dfc.properties file.|
|username||string||Username used to authenticate against Documentum.|
|password||string||Password of the user used to authenticate against Documentum.|
|The cache timeout in ms.|
|The period in ms between ACL refreshes.|
|usePrefix||boolean||true||if true, each ACL returned by the group expansion component will be prefixed with: dctm://server:port/docbase@, if false, no prefix will be used and the ACL is returned as extracted.|
<component name="DCTMGroupExpansion" subType="groupExpansion" factoryName="aspire-documentum-connector"> <docBase>documentum</docBase> <username>Administrator</username> <host>10.10.40.64</host> <dfcPropsFilePath>config/dfc.properties</dfcPropsFilePath> <debug>true</debug> <password>pass1234</password> </component>