Security and roles

Within the TCM application, security roles control what each user can view, edit, and delete within a teamspace.

NOTE  Some objects (primarily documents) may be visible or accessible from a TCM teamspace, but may actually reside outside any teamspace. The security for these objects is managed by another application, such as Workplace or Enterprise Manager, and is outside the control of the TCM application. Refer to Work with security (within the Workplace help) for information on how to control security for Workplace objects.

For information on security, refer to the following topics:

If you have sufficient security rights to modify the security files, refer to the following topics:

For an example of how to add a new security role, see Adding a new security role for teamspace members.

Fundamentals of TCM Security

The TCM application provides three default roles. You or someone at your facility will probably create additional roles or customize the default roles to accommodate your enterprise requirements. The following sections provide the background information you should have before you begin customizing the security settings for the TCM application.

NOTE  Teamspace security is based on the assumption that the enterprise administrator should control security, not the application users. Teamspace administrators may add and remove members from a teamspace and set a member's role. But teamspace administrators may not set security on objects at the ACL level. They can only assign members a pre-defined role. Updates to object security are performed by Collaboration Services back-office programs.

Permission to create teamspaces and teamspace templates is not controlled by TCM security roles. The site administrator must configure security for the Teamspaces folder (in the Root Folder for the TCM application installation) and Teamspace Templates folder (in the Root Folder\Collaboration Store folder for the TCM application installation) to control which users can and cannot create subfolders in these folders. A user must have sufficient permission to create a subfolder in these folders in order to create a teamspace or a teamspace template, respectively.

Security Roles

As each user is added to a teamspace, they are assigned a "role" within the teamspace. These roles are defined by the TCM system administrator or another person responsible for customization of the application. A role provides a set of rules that determine what the user can do with teamspace objects within the teamspace. For example, the users added using the default Teamspace Member role are allowed to view everything, actively participate in polls, meetings and discussions, add tasks, and delete the tasks they create. Other users who are added with the default Teamspace Guest role have limited access to the activities of the teamspace and cannot add anything to the teamspace. Users with an administrative role (such as the default Teamspace Administrator role) can add or remove members, delete objects, and perform other special duties.

Following are key characteristics of roles as they are used within the TCM application:

For each role there is a role definition file that specifies 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, an administrator creates or edits the file that corresponds to the role.

See also Security-related configuration files, and Customizing security roles.

Inheritance

Within the TCM application, objects are arranged in a hierarchy of folders (or "containers") within a teamspace. This means that collaboration objects (tasks, meetings, folders and documents, for example) have a parent-child relationship. Security uses this parent-child relationship in the sense that most child objects inherit security settings from their parent object by default. The security characteristics of a folder are passed down to the documents and sub-folders contained within the folder. (There are ways to sever the security inheritance and specify other security settings on a child object, if needed. See Documents for more information.)

For example, consider a document added to a folder. The document is associated with either the top-level Documents folder or a subfolder under the Documents folder, depending on which folder it was added to. Because of the inheritance model, each added document has the same security characteristics as the folder it resides in. By default, subfolders also inherit the security characteristics of the parent folder.

Anyone, such as the administrator, who can delete a folder, can also delete an individual file or document in that folder. A user with a role that does not provide delete permissions for a folder will not be able to delete individual files or documents, unless specifically given delete rights for files. The only exception is for the creator of a file or folder. By default, owners have special rights for the objects they create so that they can delete the objects that they created.

NOTE  Security is not inherited by objects if they can be separately selected for security settings. For example, each container or top-level folder (the Polls folder, Email folder, and the Discussions folder, for example) is separately securable so it does not inherit security from its parent.

Security-related configuration files

The following table summarizes the files that control security for the TCM application. You can modify these files to customize security for your installation. When TCM is installed, these files reside on the content engine in the Collaboration object store. From within Enterprise Manager, navigate to the Collaboration object store, then open Root Folder. Open the Collaboration Store to access the Collaboration Enterprise Security Definitions file and the Collaboration Access Alias Definitions file. Navigate to the Security Roles folder to display the list of Teamspace Role Definition files. You can administer these files as you would any other file in Enterprise Manager.

   

Collaboration Enterprise Security Definitions.xml example

This file defines security settings that apply to the entire collaboration object store.

This file also controls who can access teamspace templates. By default, any member of the #AUTHENTICATED USER group has view access to the teamspace templates. Users must have view access to a template to be able to create other teamspaces from the template.

For more information see Customizing the Collaboration Enterprise Security Definitions.xml file.

Collaboration Access Alias Definitions.xml example

This file defines all of the available access aliases for the enterprise. By default, TCM security provides a number of access alias definitions.For a list of the files and a description of each see Default access alias definitions.

Teamspace Administrator Role.xml example

 

For each role defined in the enterprise there is a role definition file. Each file controls the specific security aspects for all users with that role within a teamspace. When a role is assigned to a teamspace member, this role determines the member's Content Engine security for objects.

A role definition consists of a list of objects, and the access alias(es) that defines the security for that particular type of object. For example, an administrator might be granted view-rights for emails (meaning they can read them but have no other special abilities) but may have administrative rights for teams, topics, or other teamspace objects they may need to delete.

For more information on how these roles are defined, see Rights granted to the default teamspace roles.

Teamspace Member Role.xml example

 

Teamspace Guest Role.xml example

 

 

User roles and access alias rights and permissions

By default, the TCM application provides three roles – Teamspace Administrator, Teamspace Member, and Teamspace Guest. For information on how these roles are defined, see Teamspace security roles vs. enterprise security. A system administrator can change the definitions for each of these roles by manipulating the role definition files and access aliases. A system administrator can also define new roles to satisfy the requirements of a particular installation.

A role, once defined, is available to all of the teamspaces in an object store. For this reason, roles should be designed so that they are applicable to different collaboration activities. Roles should also be named so that others will have a clear understanding of the intended use. Anyone who creates a new teamspace or adds members to a teamspace will need to select a role for each teamspace member.

A role is defined by its associated role definition file. (See the Teamspace Administrator Role.xml file for an example.) The definition files provided for the default roles are Teamspace Administrator Role.xml, Teamspace Member Role.xml, and Teamspace Guest Role.xml. Each file provides a list of the various teamspace objects and the access alias that is assigned to each object. The access alias controls what the user can do with respect to that type of object. For example, if the view-rights access alias is assigned to poll objects, users with that role can view polls, but cannot create, edit, or delete them. They would need a different access alias (such as modify-rights) to edit or delete poll objects.

An access alias is a set of rights and permissions. For each type of object available in the teamspace, the role definition file defines the access alias. The role definition file assigns an access alias to each type of collaboration object, and thereby defines the permissions the user with that role has for each object in the teamspace. In the example below, the role of Teamspace Member is granted author rights for discussion objects.

See Customizing security roles for details on using and customizing roles and access alias definitions.

Enterprise security

The enterprise security file (Collaboration Enterprise Security Definitions.xml) defines security settings that apply to all teamspace-related objects that are created in an object store. The enterprise security settings control what actions are allowed for users, even if they are not members of a teamspace. By default, enterprise security provides the following:

Enterprise security rights are applied to objects but do not define capabilities for users. For example, you cannot use enterprise security to allow non-members to participate in discussions.

See also Customizing the Collaboration Enterprise Security Definitions.xml file.