Appendix A: Access Control Model in WebSphere Portal V5

 < Day Day Up > 

This appendix gives an overview of the access control model in WebSphere Portal Server V5. It is intended as a summary guide.


The access model for WebSphere Portal Server V5 is based on roles and uses inheritance. This appendix will give a summary of the key concepts required to give an overview. Other topics not covered here include ownership, private pages, traversal support. These and full details can be found at WebSphere Portal V5 Info Center:


Key concepts

Role type

This is simply a set of permissions grouped together, for example edit and view permissions. It is associated in the real world with a type of user, for example a viewer who only has read access while an editor has read/write access. Examples in Portal are User, Privileged User, Manager, and Editor. There is also a role type hierarchy where the child permissions traverse up the tree. The following diagram show the role types in Portal with a summary definition of their permissions and the overall hierarchy..

click to expand
Figure 6-21: Role type definition and hierarchy


This is the object that the access control permissions are acting upon, for example, a page or a portlet. A virtual resource is a special type of resource, typically parent resources, for example, Web Module resources. Virtual resources are also intended to protect sensitive operations that affect whole portal concepts (for instance executing XMLAccess scripts). Resources are arranged in a hierarchy, such as a parent portal, then its pages and then the portlets on the pages. Access control is propagated down the hierarchy. Please refer to the WebSphere Portal Info Center for the complete hierarchy.


This is a set of permissions on a particular portal resource. Since we define a role type as a set of permissions, a role is a role type associated with a resource, written as RoleType@Resource. It is this role which is then assigned to a user or user group.

Users/user groups

These are the entities to which a role can be assigned. They can have multiple roles on the same resource. It makes sense from a performance and maintainability standpoint to assign roles at a group level instead of assigning roles to individual users. For example, the marketing team user group can be assigned an editor role on the marketing page.


This is the key player in the WebSphere Portal Server access control model. Access control is propagated down the resource hierarchy. For example, if a user group has editor access on a page then that user group will have editor access on all the subpages. Pages inherit their access control configuration from their parent page while concrete portlets inherit their access control configuration from their parent applications.

Inheritance changes when a resource is externalized. If a resource is externalized, and its parent resource remains internal, then the external resource no longer inherits role assignments from the internal parent resource. Externalized resources can only inherit role assignments from other external resources and can only propagate role assignments to other external resources. The opposite rule applies to internal resources. There is no inheritance of role assignments from external to internal resources, only internal to internal. Externalizing a portal resource will automatically externalize all of its the child portal resources and vice versa for internalizing a portal resource.

Role blocking

This means preventing the normal inheritance cascade along the resource hierarchy. It takes twoforms:

  • Inheritance blocks- prevents a resource from acquiring its parent role assignments.

  • Propagation blocks - prevents a resource from distributing its role assignments to its children.

Virtual users and groups

WebSphere Portal contains a number of pre-defined users and groups that are not defined in user registry. Roles can be assigned to those virtual user groups in the same way as to members of the user registry. The following three virtual user groups are defined:

  • Anonymous Portal User

    This is a portal user that has not yet logged into the portal. Therefore, it is used for the portal Welcome page and for creating pages for non-authenticated users.

  • All Authenticated Users

    This is the set of all users that have logged on to the portal and are therefore known by the system. Roles assigned to the All Authenticated Users user group apply to all logged-on users of the portal. This is a way to set up the default privileges.

  • All User Group

    This user group contains all user groups except virtual user groups.

Delegated administration

Administration authority in WebSphere Portal concerns those who can modify access control or create/delete role blocks. Subsets of administration rights can be deletaged to other users and user groups. These users and user groups can then in turn delegate a subset of their privileges.

Initial settings

After the initial install, the following access control settings are available.

Table 6-1: Initial WebSphere Portal Server V5 access control settings



Administration user defined during install.


wpsadmins user group


All Authenticated Users

User@ the following portet appications:

  • Edit page content and layout

  • Concrete Properties Web App

  • Welcome

  • Appearance Web Application

  • Set Permissions Portlets

  • Information Portet Application

Privileged User@ the following pages:

  • My Portal

  • Page Properties

  • Organize Favorites

  • User/group Role

 < Day Day Up > 

Secure Portal. Using Websphere Portal V5 and Tivoli Access Manager V4. 1
A Secure Portal Using Websphere Portal V5 and Tivoli Access Manager V4.1
ISBN: 073849853X
EAN: 2147483647
Year: 2003
Pages: 73
Authors: IBM Redbooks © 2008-2017.
If you may any questions please contact us: