In my Portal navigation explained I described how the portal is executing the navigation. As the roles are loaded from the PCD, the user needs to have end-user access to the PCD. With this access, he can read the content of the roles and create his navigation. To show you what this means for your PCD and security structure, consider this scenario:
|User A||User B|
|The content is an KM document iView (image).||There is no content under the B-Sub 1 navigation.|
Applying our knowledge about portal navigation, we know that we can construct an URL and pass the parameter of the navigation target. Combined with the fact that the user needs end-user access to the PCD to read the content inside a role, user B can construct an URL that points to a navigation point outside of his own role.
User B can use the short URL for “A – Sub 1” (navurlurl://8397ca2e7d7ed7076dcb81c7632072bf): http://www.sdn.sap.com/irj/portal?navigationtarget=navurl://8397ca2e7d7ed7076dcb81c7632072bf
User B can access the navigation of user A (Role A Document) and see the iView assigned solely to Role A. Why is this possible? Take a look at the default permissions for the portal:
|SAP Help: Default Permissions: [link]|
– Administrator: read
– End user: enabled
When applying a similar permission scheme to your PCD, the users can access the navigation and the iViews of a different navigation. The navigation uses a navigation target to resolve the PCD location of the navigation target. When the user has the permission “Administrator: read” the user can access the PCD:
There is an article on SDN on how to change the permissions:
|SDN Article: [link]|
When you change the PCD permissions to be stricter, you can take away the Administrator permissions. Doing so, direct access to the PCD is no longer possible for the user.
Result for user B when accessing the iView via role or when accessed directly:
Portal runtime error.
An exception occurred while processing your request. Send the exception ID to your portal administrator.
In the NWA log viewer this error resolves to:
com.sapportals.portal.pcd.gl.PermissionControlException: Access denied (Object(s): portal_content/tobias/com.tobias.blog/com.tobias.doc)
As you can see, assigning users to roles doesn`t mean that they are unable to access content from other roles. To make sure that users won`t be able to retrieve information, check the PCD permissions. Organize your PCD content in such a way that only the users of the role can access the content.
The PCD permissions and the related error messages are not only interesting for security issues. A common error is to redirect users to a PCD location where they don`t have access to. May it by a forwarded link or a Web Dynpro application using portal navigation. When a user gets this error message in the portal:
The user hasn`t the permissions to access the content. Find out to what object (role, workset, page, iView) the user doesn`t have access and give him the permissions. To continue the above example:
In the PCD:
The permissions for user B to access the iView: