Library access control example
This example shows how item type roles can be used to grant different groups specific access to different features in the authoring portlet.
In this example, item type roles will be applied to the following groups:
Table 1. Groups
| Group
| Details
|
| WCMAdmins
| Members of this group require access to all features of the authoring portlet.
|
| SiteAdmins
| Members of this group require access to all features of the authoring portlet except workflow.
|
| SiteDesigners
| Members of this group require access to content items, presentation templates, authoring templates and components.
|
| ContentAuthors
| Members of this group require access to content items and components.
|
| ContentApprovers
| Members of this group require access to content items only. |
Library access
The simplest method of setting library access is to grant "contributor" access to all groups. This gives all users and groups "contributor" access to the library and authoring portlet. Additional access is then granted to each group using resource permissions. You can also grant the "Anonymous Portal User" group "user" access to ensure all anonymous users can access the library if anonymous access is required for website.
Table 2. Library access
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
|
|
| Manager
| Yes
| Yes
|
|
| Editor
| Yes
| Yes
|
|
| User
| No
| Yes
| Anonymous Portal User
|
| Contributor
| Yes
| Yes
| WCMAdmins
SiteAdmins
SiteDesigners
ContentAuthors
ContentApprovers |
Resource permissions
Set the following resource permissions for each role type:
- The "WCMAdmins" group is assigned the "administrator" role for all resources.
- The "SiteAdmins" group is assigned the "manager role" to all resources except "workflow and workflow elements" as they do not require access to these resources.
- The other groups are assigned roles for each resource as outlined below.
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
| SiteAdmins
|
| Editor
| Yes
| Yes
| SiteDesigners
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
|
|
The "SiteDesigners" group is assigned "editor" access to authoring templates as they are required to create new authoring templates.
Table 4. Components
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
| SiteAdmins
|
| Editor
| Yes
| Yes
| SiteDesigners
ContentAuthors
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
|
|
Both the "SiteDesigners" and "ContentAuthors" groups are assigned "editor" access to components as they are required to create components.
Table 5. Content
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
| SiteAdmins
|
| Editor
| Yes
| Yes
| SiteDesigners
ContentAuthors
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
| ContentApprovers |
Both the "SiteDesigners" and "ContentAuthors" groups are assigned "editor" access to content as they are required to create content items.
The "ContentApprovers" group is only assigned "Contributor" as they are not required to create new content items, but need approve access to content items during a workflow. You must also assign the "ContentApprovers" group "approve" access in the properties section of any workflow stages that "ContentApprovers" will use to approve content items.
Table 6. Presentation templates
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
| SiteAdmins
|
| Editor
| Yes
| Yes
| SiteDesigners
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
|
|
The "SiteDesigners" group is assigned "editor" access to presentation templates as they are required to create new presentation templates.
Table 7. Site areas
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
| SiteAdmins
|
| Editor
| Yes
| Yes
|
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
|
|
Only the "WCMAdmins" and "SiteAdmins" groups require access to site areas as these are the only groups who build site frameworks.
Table 8. Taxonomy
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
| SiteAdmins
|
| Editor
| Yes
| Yes
|
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
|
|
Only the "WCMAdmins" and "SiteAdmins" groups require access to taxonomies as these are the only groups who build taxonomies.
Table 9. Workflows
| Roles
| Allow Propagation
| Allow Inheritance
| User/Group
|
| Administrator
| Yes
| Yes
| WCMAdmins
|
| Manager
| Yes
| Yes
|
|
| Editor
| Yes
| Yes
|
|
| User
| Yes
| Yes
|
|
| Contributor
| Yes
| Yes
|
|
Only the "WCMAdmins" group requires access to workflow and workflow elements as this is the only group that creates workflows. The groups that use workflows do not require access to the "Workflow and workflow elements" resource permissions.
Item-level security inheritance
By default, each role's access is automatically inherited down to each item in a library. To prevent a user or group from automatically having inherited access to an item, you will need to turn off inheritance on that item.
The permissions set for item type do not automatically give you access to individual items. They only give you access to specific tasks and views within the authoring portlet.
You can also assign specific access to individual groups or users on each item.
Related tasks
Defining roles within a library
|