Out of the box HCL Portal is enabled to showcase many product features. To enable that, authenticated users / anonymous users have been granted access to various pages, portlets, URL Mappings and other artifacts. When building your custom solution you typically create your own set of Portal artifacts, leveraging some of the out of the box features like for instance the Web Content Manager Rendering portlet. Before going live we recommend to clean up the default permissions we set out of the box to limit the pages and portlets available to your users. Even though the pages might not show up since you might have coded your theme to not display them or the pages having a lower ordinal than your custom pages it is still possible to reach them by using friendly URLs or possibly search.
The easiest way to clean up the permissions is by using XMLAccess using the following steps:
1. Perform a full XMLAccess export using the ExportRelease.xml (located in PortalServer\doc\xml-samples) as input.
1. Perform a full XMLAccess export using the ExportRelease.xml (located in PortalServer\doc\xml-samples) as input.
For example the command could look like this:
c:\hcl\wp_profile\PortalServer\bin>xmlaccess.bat -user wpsadmin -password wpsadmin -url http://localhost:10039/wps/config -in C:\hcl\PortalServer\doc\xml-samples\ExportRelease.xml -out ExportRelease_Result.xml
c:\hcl\wp_profile\PortalServer\bin>xmlaccess.bat -user wpsadmin -password wpsadmin -url http://localhost:10039/wps/config -in C:\hcl\PortalServer\doc\xml-samples\ExportRelease.xml -out ExportRelease_Result.xml
2. Take a copy of the exported file and keep it as a backup. In case your change has unexpected consequences you can re-import the original file to undo your changes.
3. Modify the exported file.
Search for the strings "all authenticated portal users", "anonymous portal user", and "all portal user groups".
Search for the strings "all authenticated portal users", "anonymous portal user", and "all portal user groups".
You will see a structure like this:
In this structure you can see in the role tag in the actionset attribute which role type is assigned.
The anonymous portal user group represents all users before they login.
<role actionset="User" update="set">
<mapping subjectid="anonymous portal user" subjecttype="user" update="set"/>
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set"/>
<mapping subjectid="all portal user groups" subjecttype="user_group" update="set"/>
</role>The anonymous portal user group represents all users before they login.
The all authenticated portal users user group represents all users when they are logged in.
The all portal user groups user group represents all groups of users - it is only assigned to a user if the user is member of at least one other group. My recommendation is to not use all portal user groups user group but only leverage all authenticated portal users user group unless there is a very special use case.
The role types Portal assigns out of the box are either User or Privileged User role. While User on a page or portlet only grants the user the permission to see the resource, Privileged User also grants the user the ability to customize his own instance or create a private instance. For pages this means the user can create a private page below the parent page he has access on or create a private copy of the page he has access on. For portlets if the user has Privileged User on the page and the portlet he can modify the configuration of the portlet on his private copy of the page.
Unless there is a use case to allow end users to customize pages and / or portlets or create private pages you should remove the Privileged User role assignments for all authenticated portal users user group. In case you require the user to have access to view the page or portlet you could replace the access with the User role.
Unless there is a use case to allow end users to customize pages and / or portlets or create private pages you should remove the Privileged User role assignments for all authenticated portal users user group. In case you require the user to have access to view the page or portlet you could replace the access with the User role.
As a sample check the permissions for the page Web Content Management that is used for authoring - by default Privileged User is assigned. In the sample below we show the xmlaccess snippet before and after the change to remove the assignment of the role to all authenticated and assigning the role to a certain new group that represents the users that can author content.
Before:
<role actionset="Privileged User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set"/>
</role>After:
<role actionset="User" update="set">
<mapping subjectid="cn=authors,ou=users,dc=com" subjecttype="user_group" update="set"/>
</role>
<role actionset="Privileged User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="remove"/>
</role>Caution: There are a few assignments that you likely do not want to remove: The login page (unique name is wps.Login) and login portlet (unique name is login.war) and in case you are allowing signup or edit my profile, the edit my profile page (unique name is wps.Selfcare) and portlet (unique name is selfcare.war).
4. After modifying the file reimport the modified file with XMLAccess.
For example the command could look like this:
c:\hcl\wp_profile\PortalServer\bin>xmlaccess.bat -user wpsadmin -password wpsadmin -url http://localhost:10039/wps/config -in C:\CleanupPermissions.xml -out C:\CleanupPermissions_Result.xml
For example the command could look like this:
c:\hcl\wp_profile\PortalServer\bin>xmlaccess.bat -user wpsadmin -password wpsadmin -url http://localhost:10039/wps/config -in C:\CleanupPermissions.xml -out C:\CleanupPermissions_Result.xml