This information is for system administrators responsible for customization of security roles and access rights for all teamspace members and guests. This section includes the following topics:
The creator of a teamspace adds members to a teamspace and assigns each member a role, but cannot modify the rights granted by the role. See also Security and roles. For this reason, the administrator should design roles that are applicable to all of the teamspaces within the object store.
System administrators responsible for customizing security should also refer to Customizing the Collaboration Enterprise Security Definitions.xml file.
For each role there is a definition file that specifies all of the security rights for users with that role. For example, the Teamspace Administrator Role.xml file provides the security definition for teamspace administrators. To add other roles, or change what a role is allowed to do, you create or edit the corresponding role definition file.
A role definition file consists of a list of object types and the set of permissions associated with that object for that role. For the default teamspace administrator, the list of objects includes tasks, teamspaces, polls, meetings, etc., and the permissions for each object that allow the administrator to read, edit, and delete the object. Refer to the example of the Teamspace Administrator Role.xml file.
If you examine the xml file, you see that you can include one access alias within another access alias. For example, the modify-contents-rights access alias includes the modify-properties-right access alias plus additional permissions. This means that modify-contents-rights will have the same permissions as the modify-properties-rights access alias, plus additional permissions.
Within TCM, the owner of an object (task, poll, folder, etc.) has special rights with respect to security. By default, an owner has full control for an object, and can delete or modify objects that they normally would not be able to modify or delete. For example, a user may not normally be able to delete a topic in a discussion forum. However, if that user is the owner, then they will have the ability to delete it. See Special security rights for owners for more information.
See also Security-related configuration files.
You use access aliases within the definition of a role to define exactly what rights members of that role have for each type of collaboration object. To customize security for your installation, you can use an access alias by itself or in combination with other permissions to assign rights for a specific object type to a particular role. You make these assignments within the XML file for the role. (Example role files include Teamspace Administrator Role.xml, Teamspace Member Role.xml and Teamspace Guest Role.xml files in a default configuration.)
For example, examine the Teamspace Member Role.xml file. The following code gives the Teamspace Member role author rights for discussion objects. This defines what a user with the Teamspace Member role is allowed to do with respect to discussions:
To determine exactly what "author-rights" means, examine the Collaboration Access Alias Definitions.xml file. The author-rights access alias is defined within the Collaboration Access Alias Definitions.xml file as follows:
You can see that "author-rights" is defined by another list of access aliases. Each of the rights included in the definition of author-rights is defined in more detail in the Collaboration Access Alias Definitions.xml file, as well. An access alias can be constructed from other more specific access aliases, and from permissions (such as PERMISSION_RIGHT_VIEW_CONTENT) that are defined on the Content Engine.
TCM provides a set of preconfigured access alias definitions that you can use to build your own custom role-based security levels.
You may find that you want to create a new access alias definition, or modify the permissions granted by an existing one. You can do this by editing the Collaboration Access Alias Definitions.xml file. In most cases, you will not need to define new access aliases from the granular permissions, but rather you should be able to create the aliases you need by combining the existing ones. See Default access alias definitions for more information.
As you examine the access alias definitions contained in the Collaboration Access Alias Definitions.xml file, you can see that many of the access aliases are actually combinations of other permissions and access aliases. For example, the access alias called “view-rights” provides the permission to view the contents of an object (PERMISSION_RIGHT_VIEW_CONTENT). Since an access alias is also hierarchical, the “view-rights” access alias also includes the right to view properties of the object by including a “view-properties-rights” access alias.
When you are designing your own security, use this same technique to build custom access aliases using include statements to include a hierarchy of access aliases as building blocks. This allows you to reuse some general definitions, and build complex security definitions out of smaller modules. The diagram below illustrates how the sysadmin-rights access alias is actually made up of a combination of other access aliases and security rights.
The various access alias definitions (from the Collaboration Access Alias Definitions.xml file) are used as building blocks to construct complete security definitions for all types of users defined for the enterprise.
There is a definition file for each role. By default, TCM provides three roles – Teamspace Administrator, Teamspace Member, and Teamspace Guest. For more information on how these roles are defined, see Rights granted to the default teamspace roles. You can also define new roles to satisfy the requirements of your particular installation.
For example, you might want to define a new role of Discussion Moderator. This role is very similar to the default role of Teamspace Member, except that this role provides system administrator rights for all discussion objects. Users assigned the Discussion Moderator role can edit and delete any discussion objects in the teamspace.
To create this role, you could make a copy of the Teamspace Member Role.xml file, and replace the "author-rights" access alias for discussions with the access alias "admin-rights." (Note that you also need to change the name and label for the role at the top of the file.)
NOTE If you delete or rename a role you must remove any occurrences of that role in any other configuration files. See Additional considerations when deleting or renaming existing roles for more information.
When you need to create new user roles, you can use the Security Worksheet to plan the permissions you want to grant to the members of the role for each teamspace object. See Example security worksheet - Discussion Moderator Role for an example of the worksheet completed for the Discussion Moderator.
For an example of how to create a new security role, see Adding a new security role for teamspace members.
Following is a summary of the rights granted to members based on one of the three default roles: Teamspace Administrator, Teamspace Member and Teamspace Visitor. When you create a new role, use these as a guide for designing your own customized security roles.
Object |
Access Rights |
Comments |
discussions |
admin-rights |
Grants right to create and delete forums. |
forum | admin-rights | Grants right to add topics to a forum and to delete any user's topic in a forum. |
topic folder |
admin-rights |
Grants right to add postings, delete any user’s postings and to delete any user’s discussion topic. |
meetings |
admin-rights |
Grants right to add and delete meetings. |
meeting | admin-rights | Grants right to update meetings, and add or remove participants. |
polls |
admin-rights |
Grants right to create polls and to delete any poll created by another user. |
pollresponses | admin-rights | Grants right to add or delete poll participants. |
relationships | admin-rights | Grants right to create or delete relationships. |
emails |
view-delete-rights |
Grants right to view and delete email. |
teams |
admin-rights |
Grants right to create teams and assign and remove users from any team, or delete any team. |
teamspace |
admin-rights |
Grants right to add content documents and folders to the Teamspace. |
internalfolder |
admin-rights |
Grants right to create containers in a teamspace. |
members |
admin-rights |
Grants right to add and remove members. |
usersubscriptions |
create-update-all-rights |
Grants rights to subscribe to objects and events. |
engineentries | create-update-all-rights | Grants right to send commands to Collaboration Engine. |
tasks |
admin-rights |
Grants right to create tasks and delete any task created by another user. |
registeredcontainers | author-rights | Grants right to register containers with a teamspace. |
deactivateteamspace |
author-rights |
Grants right to deactivate a teamspace. |
Object |
Access Rights |
Comments |
discussions |
author-rights |
Grants right to create discussion topics |
forum | author-rights | Grants right to create discussion forums |
topicfolder | create-update-all-rights |
Grants right to create and update topics |
polls |
create-update-mine-rights |
Grants right to create polls, may only update user's own polls. |
pollresponses | create-update-all-rights | Grants right to create and update poll responses. |
meetings |
author-rights |
Grants right to create objects in the meetings folder (meetings). |
meeting | create-update-mine-rights | Grants right to update meetings, and add or remove participants for user's own meetings. |
relationships | create-update-mine-rights | Grants right to create relationships and delete/update user's own relationships. |
emails | view-rights | Grants right to view email. |
teams |
view-rights |
Grants right to view teams and the members of a team. |
teamspace |
author-rights |
Grants right to add content documents and folders to the Teamspace. |
internalfolder |
view-rights |
Grants right to view containers and other folders. |
members |
modify-contents-rights |
Grants right to update my email address in the member object. |
usersubscriptions |
create-update-all-rights |
Grants rights to subscribe to objects and events. |
engineentries | create-update-all-rights | Grants right to send commands to Collaboration Engine. |
tasks |
create-update-all-rights |
Grants right to create tasks. |
registeredcontainers |
view-rights |
Grants right to view sub-containers registered with the Teamspace. |
Object |
Access Rights |
Comments |
discussions |
view-rights |
Teamspace guests can view objects, but cannot modify them |
forum | view-rights | |
topicfolder |
view-rights |
|
polls |
view-rights |
|
pollresponses | view-rights | |
meetings |
view-rights |
|
meeting | view-rights | |
relationships | view-rights | |
emails |
view-rights |
|
teams |
view-rights |
|
teamspace |
view-rights |
|
internalfolder |
view-rights |
|
members |
view-rights |
|
usersubscriptions |
create-update-all-rights |
Grants rights to subscribe to objects and events. Required to support subscriptions. |
engineentries | create-update-all-rights | Grants right to send commands to Collaboration Engine. Required to support email. |
tasks |
view-rights |
Teamspace guests can view objects, but cannot modify them |
registeredcontainers |
view-rights |
Roles are defined by configuration files stored in the Collaboration Store. For each role, ACL permissions are specified for every unique type of collaboration object, defining a complete set of permissions for collaboration objects for a given role. See Low-level permissions for a list of the ACL permissions.
Member-based permissions are applied to all teamspace objects when they are initially created. Member-based permissions are updated whenever a member is added or removed from a teamspace. The security update is performed via a command issued by the Collaboration API. The API does not directly update security since at the time of membership update, the current signed in user most likely does not have rights to modify security on persistent collaboration objects.
NOTE Teamspace security concepts assume that the enterprise should control security and not end-users. Teamspace administrators can add and remove members from a teamspace and select each member's role. But the default Teamspace Administrator role does not grant the right to set security. They can only assign members a pre-defined security role. Actual updates to object security are performed by Collaboration Services back-office programs.