Access roles and the Web Content Management authoring portlet

Any member of the Workplace Web Content Management administrators group (usually called wcmadmins) can access the authoring portlet, and will have full control and access to all of the objects in Workplace Web Content Management. However, this is only one of the ways in which you can control access to the contents of the authoring portlet. Workplace Web Content Management administrators can edit, create, and delete anything in the authoring environment. You want to have more control than that -- for example, you may have some users who should only be able to create pure content, and should have no control over the rest of the items. Or, you may have a group who can create sites and site areas, but have no say over the content that goes into them. This is where controlling access to the authoring portlet comes in.

There are three different access levels for the authoring portlet:

  • No access means users will not be able to read or edit those items in the authoring portlet. Even if they have specifically been granted access at the object level, if they haven’t been granted any access at the Workplace Web Content Management authoring template level, they will not see these items in the authoring portlet.
  • View/read access allows users to view and read existing items, but not edit them or create new items in these categories. For you to have access to an object, you also have to have been granted access at the object level. Also note that if you have been granted edit/delete access at the object level, even though you only have view/read access at the category level, you will still be able to edit/delete that object.
  • Management access allows you to edit, create, and delete items in this category. Again, for you to have access to an object, you also have to have been granted access at the object level. So you can have management access, but if you haven’t been granted edit access at the object level, you will not be able to edit that object.

The various aspects of Workplace Web Content Management authoring are split up into 12 different categories when controlling access to the objects in the authoring portlet. The following table describes the different categories, as well as how the different levels of access affect the user when granted that access to the category.








To change the access settings for the Workplace Web Content Management authoring portlet, follow these steps:

  1. Log into WebSphere Portal as a member of the Workplace Web Content Management administrators group.
  2. Click the Web Content Management tab to access the authoring portlet.
  3. Click the Configure icon in the upper-right corner of the portlet (see figure 1).

    Figure 1. Configure icon
    Configure icon

  4. Expand Access Options. You will see the 12 categories, as well as buttons for both view/read and management access levels for each item (see figure 2). You will also see a button labeled Edit Security. At this point, you have two options. You can click the Edit Security button to mass update the settings, or you can click the Add/Remove buttons for grant view/read or management access in the individual categories. For this example, let's click Edit Security.

    Figure 2. Access Options (Edit Security button highlighted)
    Access Options (Edit Security button highlighted)

  5. You are presented with a screen where you can select the users and groups that you want to grant access to (see figure 3). You can choose the access level users will have for each category. Click the Add button to add items.

    Figure 3. Change the Security level of selected items dialog
    Change the Security level of selected items dialog

  6. On the next screen (see figure 4), choose either users or groups to search -- you can search for either. We recommend using groups to control access to objects. In the example shown in figure 4, we have searched groups for Content_Creators. After this is found, we select it by checking the checkbox, and then clicking OK.

    Figure 4. Search for Users or Groups dialog
    Search for Users or Groups dialog

  7. You now see the group listed on the screen where you can set the access levels. For each of the 12 categories, there is a drop-down box to select the access that you want the users/groups to be granted. In this example, we select Grant Management Access for all 12 categories, and then click OK.
  8. The Content_Creators group is now listed under the Management Access for all 12 items (see figure 5).

    Figure 5. Content_Creators group
    Content_Creators group

  9. Click OK to apply these changes.

Portal access to the Web Content Management viewer portlets

Members of wcmadmins also have automatic access to the other two Workplace Web Content Management portlets, the remote rendering portlet and the local rendering portlet. If you want other people to be able to edit these portlet settings to determine what content they will be displaying, you have to grant them that access as well. Unlike the Workplace Web Content Management authoring portlet, this access is granted through the portal administration, and the WebSphere Portal Administrator (or someone who is a member of that group) will have to grant that access.

To grant the necessary access, do the following:

  1. Log in as wpsadmin, or another member of the wpsadmins group.
  2. Click the Administration link in the upper-right corner. This will bring up the portal administrator information.
  3. Click the Portlet Management link, and then Portlets. This will present you with a list of all the portlets. Find the portlet that you want to edit the access on. In this case, we will be granting access to one of the local rendering portlets.
  4. Change "Search by" to "Title Contains," and enter "Web Content Viewer� in the search term text box.
  5. Click the Search button. This will display a list of the Workplace Web Content Management portlets (see figure 6).

    Figure 6. Workplace Web Content Management portlets
    Workplace Web Content Management portlets


    In figure 6, we have both local and remote rendering portlets deployed. Note that if you make copies of the portlet, you have the ability to name the portlet anything that you like. So you should change your search term accordingly.
  6. Click the “key� icon next to the portlet that you want to grant the access for configuring the portlet. This displays the list of access options.
  7. In this case, we want to grant the user Editor access to the portlet, so click the edit role (the pencil) in the Editor column.
  8. The next screen displays users or groups who have been added to this role. Click the Add button to add a new user/group.
  9. You are now able to choose what group/user you want to grant the access to. Our example selects a group, and searches for Content_* (see figure 7).

    Figure 7. Resource Permissions dialog
    Resource Permissions dialog

  10. Choose the user or group you want to add by selecting the checkbox next to the name, and click OK.
  11. You have now added the user. To exit the screen, click the name of the portlet link in the upper left, so you can return to the current security mappings. Then click the Done button.

For users to be able to see the portlets on a page, they will have to have at least user access to that portlet. You can grant user access level by following the preceding steps.

Web Content Management remote rendering portlet authentication

The Workplace Web Content Management remote rendering portlet needs to establish a connection to the server that the Workplace Web Content Management content is stored on. Therefore, it needs to pass credentials to establish the connection. Additionally, the credentials that it uses to establish the connection are the same credentials that it will use to determine what access it has to specified Workplace Web Content Management content. There are two options for authenticating the remote rendering portlet to the remote Workplace Web Content Management server:

  • LTPA. When you specify LTPA authentication, you will use data for the user who is logged into the WebSphere Portal server where the remote rendering portlet is deployed to authenticate to the remote Workplace Web Content Management server. This means that the user has to exist in both WebSphere Portal servers in the same manner. Usually, the two WebSphere Portal servers will share the same LDAP server, so this is taken care of. So, if you choose LTPA, it will take the user information from the user who is logged in, and authenticate to Workplace Web Content Management on the remote server with that information. If you do choose to use LTPA, you will have to follow the information in the WebSphere Portal Information Center to share the LTPA token between the two WebSphere Portal servers. Basically, you export the LTPA token from one instance, and import it into the other instance. Using the LTPA token for authentication has the advantage of being able to control what the user has access to, depending on what user is logged in. When you supply a credential vault, all users of the remote rendering portlet will share one username (as will be explained later in this article).
  • Credential vault slot. A credential vault is a way that you can define a shared username and password in WebSphere Portal. By using a credential vault slot, you can set up a username and password combination. Many different resources can then reference that slot. For Workplace Web Content Management, you would give the slot a username and password that you want to use to authenticate to the remote Workplace Web Content Management server where the content will be coming from.

Using the credential vault slot for authentication has the advantage of simplifying the authentication method, for several reasons. First, you do not have to share an LTPA token. Second, all content that you want to be served through the Workplace Web Content Management remote rendering portlet can be granted live access to just one user -- the user you define in the credential vault slot. Finally, the users in the WebSphere Portal server that you are serving content to do not have to exist in the remote server as well. This means that the two WebSphere Portal servers do not have to share the same LDAP server.

To create a credential vault slot:

  1. Log into WebSphere Portal as a member of the wpsadmins group.
  2. Click the Administration link in the upper-right corner. This will bring up the WebSphere Portal administration page.
  3. Click the Access link on the left.
  4. From the options that are displayed, click Credential Vault. This displays the credential vault page.
  5. Let’s give the Workplace Web Content Management Remote Rendering Portlet its own vault and vault slot. Click the Add a Vault Segment from the menu.
  6. Leave the Vaults field at the default, and don’t worry about the values in the “Resources within selected vault� field. For the vault segment name, enter a name you would like to use for the vault segment (we used WCMVaultSegment). Enter a description if you would like (see figure 8).

    Figure 8. Credential Vault dialog
    Credential Vault dialog

  7. Click OK. This will bring you back to the main credential vault page.
  8. Now that you have created a vault segment, let’s create the credential vault slot. Click the “Add a vault slot� link. This will display the form to create a new vault slot (see figure 9).

    Figure 9. Create a vault slot dialog
    Create a vault slot dialog

  9. Enter a name (our example uses WCM). From the Vault Segment drop-down box, select the credential vault segment that you created in the preceding steps (in our example, this is WCMVaultSegment). Under "Vault resource associated with vault slot," select New and give the new resource a name (for example, WCM). Select the “Vault slot is shared� checkbox, and enter the username and password that you will use to authenticate to the remote Workplace Web Content Management server (for instance, wpsadmin). If you wish, enter a description. When finished, click OK.

You have now created a credential vault slot that you can specify in the remote rendering portlet settings. When you are asked the credential slot name, enter whatever you named the vault slot. In our example, this would be WCM.

Workplace Web Content Management access levels

There are five different access levels that can be assigned to objects in Workplace Web Content Management:

  • No access means that the user has no access whatsoever to the content. This is the default level of access to Workplace Web Content Management objects, because until you specify that a user has access (either directly or through inheritance of the group security), the only user who has access to an object is the author. The exception to this is any member of the Workplace Web Content Management Administrators group, who will have full access to all objects in Workplace Web Content Management.
  • Live access is the minimum access that a user requires to a Workplace Web Content Management object to see the object displayed/rendered on a Web page. Live access means that the user has access to view the object when it is rendered, but that is all. They will not have access to the Workplace Web Content Management object/document itself.
  • Read access lets the user see the actual document for the Workplace Web Content Management object. This means that the user will see the object in the Workplace Web Content Management authoring portlet, and will therefore be able to reference that object when either configuring portlets to point at that object, or creating new objects based on the object.
  • Edit access allows the user to edit the object.
  • Delete access grants the ability to delete the object from Workplace Web Content Management.

Note that access levels inherit from the levels that are “lower� than they are. This means that if a user has edit access, they also have read and live access, and so on.

For example, consider an authoring template named TestSecurityAuthTemplate. Let's say the group Content_Creators has been granted read access to the authoring template (see figure 10).


Figure 10. TestSecurityAuthTemplate template
TestSecurityAuthTemplate template

The group has read access on the authoring template, so when they create a new piece of content, they will be able to select that authoring template for the new content (see figure 11).


Figure 11. Selecting TestSecurityAuthTemplate
Selecting TestSecurityAuthTemplate

This is the minimum access that the user must have if they are going to choose the Workplace Web Content Management object for use in either the local or the remote rendering portlet. If the user only has live access, or no access at all, they will not be able to choose the object in the Workplace Web Content Management viewer portlets.

User-defined, system-defined, and workflow security

When access is set for a Workplace Web Content Management object, it can be defined in three ways.

  • User-defined access can be added and removed by anyone who has edit access to the object. If you are not an administrator, you can only grant user-defined access. If the object is participating in a workflow, the user will not be able to grant user-defined access.
  • System-defined access can only be added and removed by a member of the wcmadmins group. This means that if an administrator has granted system-defined access to an object, no author who is not a member of the wcmadmins group will be able to remove that access.
  • Workflow security is the access levels that the object receives from the workflow stage that the object is in. If the object is participating in a workflow, it will get its access levels from the current workflow stage. Note that if the object is participating in a workflow, the user-defined access will not be available. This means that only members of the Workplace Web Content Management administrators group will be able to grant additional access to the content.

The end result of defining the access is the same regardless of how it is assigned. If you are assigned read access on an object, you will have read access to the object if you have received it from user-defined security, system-defined security, or workflow security.

Workflow and workflow stage access levels

In a workflow stage, you define who has access to a document that is in that stage in the workflow. The access level that you grant is only applicable to objects in that particular workflow stage. Using these different levels of access in workflow stages, you can control who has the ability to edit a piece of content while it is in any particular stage of the workflow.

For example, let’s say you have a workflow with three stages: Draft, Approve, and Publish. You could grant delete access to the Content_Creators group in the Draft stage, but only read access in the Approve and Publish stages. This means that members of the group are able to edit and delete objects that are in the Draft stage, but after the object moves on to the Approve and Publish stage, they can no longer make changes. This is the main idea behind workflow security settings. Administrators can have total control over which user has what kind of access to what particular object, and at which point in the workflow the user will have that access.

Workflow security has the same levels of access that we discussed earlier: live, read, edit, and delete. It also has a new level of access: approve. Approve access basically determines who has the ability to move the object to the next stage in the workflow from the stage that they have approve access on. For example, if an object is in the Draft stage, a user will have to be granted approve access in the Draft stage to be able to approve the object’s move to the next stage.

Special cases

There are two special cases involving Workplace Web Content Management security. First, any member of the Workplace Web Content Management administrators (wcmadmins) group always has full access to Workplace Web Content Management objects. This means that even if the user hasn’t been granted specific security rights on a particular object, if he is a member of the wcmadmins group, he will have full access.

Also, if an object has specified that an anonymous WebSphere Portal user has access to it, then any authenticated WebSphere Portal user also has access to that object. For example, if you grant anonymous WebSphere Portal users live access to an object, any user who logs in automatically has live access to that object as well.

Conclusion

This concludes our review of Workplace Web Content Management security. We hope you found this article helpful. By using the information we presented here, you can better manage the security of all your Workplace Web Content Management content, ensuring that the right users (and only those users) have the proper access to your corporate data.

0 comments: