Security suggestions and guidelines

Following are general guidelines for customizing your security roles.

Design and create your security roles before users begin using the application

Changes to the permissions granted by the security roles are not immediately reflected in existing teamspaces. Design and create your custom roles before you begin using the application, if possible.

If you need to change or add a security role after teamspaces are already in use, a change to the teamspace membership (adding a new member, for example) will force the teamspace roles to update for that teamspace.

Provide at least the minimum security permissions for teamspace members

In order for teamspace members to be able to participate successfully in teamspaces, they should have a minimum set of permissions, as defined by a security role. For example, if members do not have sufficient permission for forums, they will not be able to participate in discussions, because they will not be allowed to add topics or replies.

The default Teamspace Member role provides an example of the minimum permissions that a typical teamspace member should have. See Example Teamspace Member Role.xml file for an example.

Each teamspace should have at least one administrative member

Each teamspace should have at least one member with administrative rights so that they can manage the teamspace membership and perform other actions that may be required such as deleting obsolete or unwanted objects.

When you are determining what types of user roles you need for your installation, be sure to include at least one administrative role with full access to all of the TCM objects. This ensures that someone will be able to delete, edit or otherwise modify any objects, if needed.

If a role definition does not grant any permission for a type of object, users with that role will have no rights for that type of object

If you create or edit a role definition file and you do not include an object type and assign an access alias to it, users with that role will not have any rights for the object, including the permission to view the object. For example, if you edit the Teamspace Guest role to remove the permission settings for polls, below:

 <objsecuritydef>
    <objsymname>polls</objsymname>
    <accessalias>view-rights</accessalias>
 </objsecuritydef>

Guests will not be able to see any polls in the teamspace.

A user is assigned only one role in a teamspace

When designing teamspaces, consider that a user can only have a single role within a teamspace. If you create roles with very specific rights and permissions, users with that role will only be able to participate in the teamspace to a limited extent.

Additional considerations when deleting or renaming existing roles

If you delete or rename a role you must remove any occurrences of that role from the appConfig.xml file. For example, if you rename the admin-security-role, you must edit the corresponding access-levels, default-creator-role, and default-member-role settings in the appConfig.xml file so that they reflect the name of a valid security role.