Overview of Portal Access Control
IBM® WebSphere® Portal Version 5.0 introduced the Portal Access Control (PAC) authorization model to enable instance-level protection of portal resources, based on role types and role inheritance. PAC is a generic model, based on a set of simple rules and corresponding configuration artifacts that can be freely combined to create any sort of setup--from easy to complex access control.
The artifacts defined by the PAC model are:
- Protected resource
- Protected resource hierarchy
- Virtual resource
- Role type
- Role block
The next section introduces these artifacts and their associated semantics.
A protected resource represents a portal artifact (such as a page or a portlet) that is protected by PAC. Virtual resources, created during portal installation, form the root nodes of the protected resource hierarchy which holds a reference to each protected resource within the system. Individual resources are linked into this hierarchy according to their internal structure within the portal object model. For example, nested pages are linked as child pages underneath their parent pages, and portlet definitions are linked as child resources of their enclosing portlet application definition. The Security concepts => Access control section of the WebSphere Portal InfoCenter (see Resources) includes a complete discussion of the internal topology of the protected resource hierarchy.
To grant a user access to a specific resource (such as a specific page), you need to assign the user a corresponding role for this resource. Each role has an associated role type, which represents a specific job responsibility in the system. For example, an Editor role type would represent responsibilities such as creating new resources and modifying existing resources used by other users. WebSphere Portal defines a static set of role types during portal installation including but not limited to:
- Security Administrator
Roles are tied to individual resources; therefore, a given role is characterized by the corresponding role type (which defines the level of allowed access), and the set of resources that are affected by the given role. So, you could grant a group of users Editor privileges on some resources and Manager privileges on some other resources. This is a real improvement over the classical Role-based Access Control (RBAC) approach, in which roles always have system-wide scope.
In order to prevent the administrator from the burden of defining individual roles for each and every resource in the system, PAC supports the concept of role inheritance. If a user has been granted a role with a specific role type for a specific resource, that user is automatically allowed the same level of access on all descendent resources within the protected resource hierarchy (that is, nested sub-pages) through role inheritance. You can deactivate role inheritance using role blocks, which shield individual resources from being affected by role inheritance. Role blocks are role type specific. Therefore, you can prevent role inheritance for all Manager roles on a given resource but still allow Editor role inheritance.
PAC supports the notion of ownership. When a new resource is created within WebSphere Portal, the user identity that triggered the resource creation (for example, a user who installed a new portlet) becomes the initial owner of the new resource. Ownership of resource comes with a well-defined set of privileges on the owned resource, such as the ability to view, modify, and delete the resource. Ownership can be transferred to other users or even other user groups.
Each portal user's set of effective privileges is defined by the union of all privileges that come with any roles assigned either directly to the user or to any of the user's enclosing user groups, and all privileges that come with ownership. (By enclosing user groups we mean the set of user groups in the user registry that directly or indirectly contain the given user as a member.) This set of effective privileges exactly defines the operations the user can perform on individual resources in the system.
Example: In a sample configuration, Bob has the User role on the My Portal label, and he is also a member of the Administrators user group. Furthermore, Bob is (like any other user) an implicit member of the virtual user group, All Authenticated Users. In this configuration, Bob would be able to see the My Portal label, the pages below that label, and those pages and portlets which the Administrator and All Authenticated users group can access.
The PAC model enables a highly flexible access control configuration. You can grant access using concepts such as role inheritance, ownership, or group membership. The individual options, while achieving the same privilege setup, can have varying impact on overall access control performance. The following sections provide recommendations to achieve good performance by making proper use of the PAC administration artifacts.
PAC depends on a fast, reliable connection to the configured user registry (LDAP) and to the portal configuration database, as well as good performance of these systems. Check the documentation for your LDAP server and database server for information on tuning these two key systems.
- Keep the access control configuration as simple as possible.
The number of role blocks and explicit role mappings influences the access control performance. Try to avoid redundant explicit role assignments by leveraging:
- User groups
- Role inheritance
- Ownership (with groups)
Example: Do not give Bob an explicit role assignment for a resource if:
- Bob is a member of a user group that already has access to the resource
- Bob (or one of Bobâs enclosing user groups) has a corresponding role assignment on the parent resource of the given resource (and there are no role blocks in between those two resources)
- Bob is the owner of the resource
- Minimize the number of user groups.
The number of groups to which a user belongs affects the portal access control performance, because the effective permissions for a user are computed by building the union of all permissions granted to the user and all permissions granted to the userâs enclosing user groups.
Minimize the number of different groups to which the users belong. Effective permissions granted to an individual user group are cached on a per user group basis. Therefore, existing cache entries for user groups are available for all members of that group and do not need to be recomputed. If each of the users is in different groups, the caching will not help.
Example: For instance do not put Bob into group Managers if he already got the access rights associated with the Managers group from the Administrators group.
- Avoid nested group hierarchies:
The retrieval of nested groups from the configured user registry can be a very expensive operation. Try to use direct group membership instead.
Example: If you did not disable nested groups you should check if the Administrators group, you want to assign Bob to, is a member of another group, such as the Super Administrators group. If possible, assign Bob directly to this group.
- Avoid doing access control administration while the system is under heavy load.
You could trigger multiple updates using XmlAccess during off-peak hours. Whenever a role block or a role assignment is created or deleted, or a new owner is assigned to a resource, corresponding portions of the cache must be invalidated. The amount of information that actually gets evicted from the cache depends on the specific operation being performed. Users currently working with the system will experience a slower response time if the evicted information in the caches needs to be recomputed. Role blocks and the deletion of whole sub-trees are especially expensive because they invalidate huge parts of the caches.
Example: Do not delete or create a role block for a page while most of the users are logged in, using the portal. All users would experience a delay while the cache is rebuilt.
- Limit the use of external access control.
The communication with the security manager on another system takes more time than computing permissions internally. If an external security manager is really required, try to use it for a small number of resources only.
Example: Externalize only the virtual resources and the pages and portlets which contain the most sensitive information.
Tuning the access control caches
CacheManagerService.properties file, located in the
PortalServer/shared/app/config/services directory, defines the caching properties used by WebSphere Portal. The different caches are referenced by their names, and individual properties (such as lifetime or size) can be appended to the cache name. For example, the entry
identifies a property named
lifetime associated with the cache instance named
You can adjust individual cache properties to tune the associated cache instances to your specific needs:
- Determines if the cache is enabled or not. If the cache is not enabled, then the values are always computed.
Supprted values: true or false
- Determines the lifetime of the entries in the cache. An entry is invalidated when it exceeds the configured lifetime since it was added. The portal authorization component propagates modifications to access control configuration immediately within the cluster by leveraging explicit cache invalidation. Nevertheless, additional time-based invalidation is recommended for the following reasons.
- On cluster setups, there can be certain very rare situations in which some cache invalidation messages are not properly processed on each cluster node. In fact, a message can be missed by race conditions within the Application Server cache. Although, the probability for this situation to happen is very low, it currently cannot be completely prevented.
- When using external access control, role caches need to be invalidated after some time in order to reflect modifications in the external security manager where the roles have been externalized. Supported values: number of seconds. (To set the lifetime to infinite, use the value 0.)
- The number of entries allowed in the cache. If the size limit is hit, the least recently used entry is removed in favor of the new one. Supported values: number of entries
You can adjust the lifetime and size settings on these caches, which are used by the security components.
- Contains the resources protected by PAC. The size of this cache scales with the number of protected resources accessed by the active users in the system.
Example: If, at a given point in time, 500 users are operating on 20 individual resources (typically each user potentially accessing multiple resources and many resources accessed by multiple users), the ideal cache size would be 10000. If the number of active users doubles in this scenario, the ideal cache size would also double (to be 20000).
This cache is invalidated during when the resource is deleted or relocated, and when the resource state (private/shared), the resource owner, externalization, internalization, or role block is modified. Please give a specific simple example. I think if you provide one really specific example the others will be more clear, so you don't need examples for each and every oneâ¦just any that might be really different.
Example: Bob deletes a specific portal page using the Manage Pages Portlet, which removes the selected page and all sub-pages from the portal configuration database. Because portal pages are resources that are protected by portal access control, there x references may still exist to those deleted pages in the PortectedResourceCache. In order to make portal access control reflect the most current information, those references in the ProtectedResourceCache are explicitly evicted from the cache. The next time, the portal access control component requests this information, there will be a cache miss, and the most current information is read from the portal configuration database.
- Contains the owner relationship of resources. The size of this cache scales with the number of active users and groups multiplied by the different ResourceTypes they access. This cache is invalidated during resource deletion, modification of the resource owner, externalization, and logout of the user.
- Contains the role instances. Its size scales with the number of active users/groups multiplied with the different ResourceTypes they access. This cache is invalidated during role mapping creation, role mapping deletion, resource deletion, externalization, internalization, and logout of the user.
- Contains the mappings of users and groups to roles. Its size scales with the number of active users/groups. It is invalidated during role mapping creation, role mapping deletion, resource deletion, externalization, internalization, and logout of the user.
- cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.*, cacheinstance.com.ibm.wps.ac.ChildEntitlementsCache
- Contain the permissions for a user or group on a number of resources of the same ResourceType. Each ResourceType has a dedicated cache. For example, there is one for pages called cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.CONTENT_NODE. All ResourceTypes which are not explicitly specified aree cached in the default cache. The size of these caches scale with the number of active users and groups multiplied by the different ResourceTypes that are valid for the cache and that the users and groups access. These caches are invalidated during all access control modifications.
- Contains the nested groups to which a user belongs. This cache was introduced with WebSphere Portal V5.1.0. The size of this cache scales with the number of active users and the number of individual virtual portals (starting with 5.1) they access. It is invalidated when the user logs out.
- Contains the direct groups to which a user blongs. This cache was introduced with WebSphere Portal V5.1.0, and PK00044 on V18.104.22.168. The size of this cache scales with the number of active users and the number of individual virtual portals (starting with 5.1) they access. This cache is invalidated during logout of the user.
- Contains the resource hierarchy within Portal Access Control. The size of this cache scales with the number of protected resources accessed by the active users in the system. This cache gets invalidated during resource deletion, parent change of the resource, modification of the resource state (private/shared), modification of the resource owner, externalization, internalization, and role block change.
- cacheinstance.com.ibm.wps.puma.DN_OID_Cache, cacheinstance.com.ibm.wps.puma.OID_DN_Cache
- contain the mapping of the distinguished name of a user and group to the internal ObjectID identifier. This cache was introduced with WebSphere Portal V22.214.171.124 and PQ90584 on V5.0.2 and V126.96.36.199. The size of this cache scales with the number of active users and groups, or those used for delegation. This cache is invalidated during deletion of a user or group.
Figure 1 shows the relationships among the various caches. The small cylinders represent cache instances, and the large cylinders represent databases. The green caches are caches of the portal user management (PUMA) component that are closely related to the caches of the portal access control component. The Puma caches cache information originating from the user registry. Portal access control uses these caches for user identification and group membership retrieval.
The vertical axis represents the cache aggregation direction. The cache instances in 'layer' N leverage cache instances of lower layers to compute their values.
Example: When computing effective permissions (entitlements) for Bob (cached in ExplicitEntitlementsCache), the portal access control component leverages existing cache values from the ChildResourcesCache and RoleMappingCache.
Figure 1. Cache correlation to storage
Determining cache variable values
Table 1 shows how to get the values of the key variables required to compute the sizes of the caches.
|Number of ...||Source|
|Protected resources||Resources within the prot_res table. You could run an SQL query select count (*) from prot_res to get this information.|
|Frequent users in your system||Use the Frequent Users portlet to get the number of users that logged on to your system in the last 90 days|
|Groups with frequent users||Run an XMLAccess export, and only export the users and groups. Check for the different types of users you know for frequent login and count the number of groups they belong to.|
|Accessed resource types||There are around 15 portal resource types that are protected by Portal Access Control and around the same number of document management resource types (starting 5.1 around 10).|
Selecting performance configuration options
Depending on your setup, you might decide to use some of the following configuration options to modify the portal access control behavior.
Table 2 shows configuration parameters you can set in the
AccessControlDataManagement.properties file, which is located in the
directory. Each property is of the form
XXX is the Property.
|enableNestedGroups||Determines if access rights from the direct groups (false) or nested groups (true) should be inherited by the user. See the Technote: Improving response time in User and Groups portlet, Resource Permissions portlet and User and Group Permissions Portlet for more information.||V5.0.0||false||true with V5.0.0|
|enableTargetResourceGroupInheritance||Determines if access rights on users are computed using the nested (true) or direct group hierarchy (false). See the Technote: Improving response time in User and Groups portlet, Resource Permissions portlet and User and Group Permissions Portlet for more information.||V5.0.0||false||true with V5.0.0; false starting V5.02|
|enableUsersInheritance||Determines if users that are member of user groups shall inherit access rights from the virtual resource Users (true) or not (false). See Technote: Delegated Administration on Users and User Groups with WebSphere Portal Access Control for more information.||PQ97770||true||true|
|cacheTimeout||Global cache timeout for all Access Control caches in seconds. This property should be set to a high value and instead the lifetime values of the individual caches in CacheManagerService.properties file should be adjusted.||5.0 â removed with 5.1.0||high value (e.g. 1000000)||3600|
|checkUserFirst||Determines if the access rights shall be checked first for the user (true) or the groups the user is member of (false).||PQ93534||Depends upon the role setup. If roles are assigned primarily to individual users, then set to true; otherwise, set to false.||false|
|loadRolesParentBased||Determines if a special logic to load roles shall be used (true) or not (false). This logic especially makes sense in scenarios with many updates of the access control configuration.||PQ96873||This logic especially makes useful in scenarios with many updates of the access control configuration (especially role assignments and unassignments), otherwise, should be false.||false|
|doNotLoadPortletEntities||Determines whether Portlet Entities are loaded during access control computations (false) or not (true).||PQ98480||true||false|
|useGroupCache||Determines if the groups a user is member of shall be cached (true) or not (false). Changes in the group hierarchy are not directly reflected until the cache entry times out.||PK00044 â replaced by accessControlGroupManagement. cacheMode with 5.1.0 (see below)||true||false|
|checkIsLeaf||Limits the cache invalidation of resources that do not have child resources (true). This property should be set to false in concurrent update scenarios as deadlocks may occur in these scenarios.||V188.8.131.52||true||false|
|enableFastUserHasRoleHeuristic||Precomputes potential access rights of a user before the complete computation of the access rights for a ResourceType.||PK03477||false. However, if the users have no access rights, but all access rights are granted to the groups, then set this property to true.||false|
|enableFastGroupHasRoleHeuristic||Precomputes potential access rights of the groups for which the user is a member before completing the computation of the access rights. If more groups do not have access rights than have access rights this property, then set this property to true.||PK03477||true||true|
|excludeFastHasRoleTypes||Specifies those ResourceTypes for which precomputation of potential access rights should not be included. Specify as a comma-separated list.||PK03477||CONTENT_NODE, PORTLET_DEFINITION||All resource types except for the Content Management and Collaboration types|
Table 3 shows configuration parameters you can set in the
PACGroupManagementService.properties file, which is located in the
directory. Each property is of the form
XXX is the Property.
|cacheMode||Determines if the groups a user is member of shall be cached (true) or not (false). Note that changes in the group hierarchy will not be directly reflected until the user logs out or the cache times out.||V5.1.0||true||true|
|cacheTimeout||Separate timeout in seconds for the user-in-group caches independent of the lifetime of the entries.||V5.1.0||high value||3600|
Updating system service level
To get optimum performance from WebSphere Portal PAC, make sure you have the fixes to the following APARs installed on your system. These APARs are only available for certain releases and fixpacks; they are included in later versions. See the release documentation.
Auto-cleaning redundant configuration
You can use the Optimizer, a separate task, to automatically clean up redundant access control configuration such as unnecessary role blocks or role mappings. You can trigger it using an XMLAccess request . The input file should contain the following in the request tag:
Listing 1 shows a complete XMLAccess file to trigger the optimization would look like the following:
Listing 1. XMLAccess code to trigger the optimizer
<?xml version="1.0" encoding="UTF-8"?> <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PacOptimization.xsd"> </request>
In the wp_root/bin directory, enter the following command (on one line) to run XMLAccess. Replace PACOptimization.xml with the name of the XML file containing the snippet above.
xmlaccess -user user -password password -url http://myhost:myport/wps/config -in PACOptimization.xml -out result.xml
Figure 2 illustrates the basic functionality of the Optimizer.
Page1 has two children: page2 and page3. The user group g1 has the Editor role on pages 1, 2, and 3. An Editor Inheritance role block exists between page1 and page2.
The Optimizer will remove the role mapping of g1 on page3 because g1 already has the same access rights via role inheritance from page1. It will also remove the Editor Inheritance role block and the Editor role mapping on page3 if no other user or group above in the hierarchy has the Editor role. Propagation role blocks are not modified by the Optimizer, by default.
Figure 2. Optimization task example
Table 4 shows additional configuration options for the Optimizer (introduced in PQ97351) that you can set in the
AccessControlConfigService.properties file, which is located in the
directory. Each property is of the form
XXX is the Property.
|enablePrivatePageOptimization||By default the Optimizer tries to find out if implicit derived pages exist that are not flagged as private resources in PAC. This could occur after 4.x to 5.x migration. If the value is set to false this logic will not be executed, allowing a faster Optimization.||true|
|enablePropagationBlockDeletion||If the flag is set to true the propagation role blocks will be removed as well if the logic determines that inheritance role blocks may be removed. This can modify effective privileges for some users/groups.||false|
|optimizationRootResource||The root resource spanning the resource tree that shall be optimized. Either the name of a virtual resource or the unique name of a resource can be specified. By default the whole tree will be optimized.|
|optimizationRoleTypes||Comma separated list of role types that shall be optimized. Role types not contained in this list will be ignored during optimization. By default all Role Types are optimized.|
Tuning start up response time
Use the AccessControlWarmUpService to reduce the response time of access control requests by the first users accessing WebSphere Portal after a server start. This service computes the cache values relevant for the most recently logged in users or for some explicitly listed users andgroups during startup and pre-fills the access control caches accordingly.
Example: If the default values are used, the service is enabled, and a page was added with a unique name (such as wps.My Portal), the ten most recently logged-in users before shutting down the server are selected for the calculation. For these users, the permissions on the virtual resources (such as the Portal or Content-Nodes virtual resources) and the content nodes are computed. The set of permissions for the users and the permissions of the groups, of which the users are members, are computed as well. All of this happens during portal startup.
If, after the startup, a user accesses the portal, the permissions for the groups will not need to be recomputed if the user is a member of one of the groups that was computed during startup.
The AccessControlWarmUpService was introduced with PQ97210 and PQ97613. Table 5 shows the properties which you can set by modifying the
AccessControlWarmUpService.properties file, which is located in the
directory. Each property is of the form
XXX is the Property.
|enabled||Determines if the AccessControlWarmUpService is enabled (true) or not (false).||false|
|numberOfMostRecentUsers||Specifies the number of most recently logged-in users to be used for pre-filling the caches.||10|
|numberOfUsers||If this property is set to a value > 0, a certain set of users can be specified explicitly with their Distinguished Names using
|numberOfGroups||If this property is set to a value > 0, a certain set of groups can be specified explicitly with their Distinguished Names using
|numberOfUniquenames||By default the permissions are only computed for the virtual resources. If this property set to a value > 0, for a certain set of resources identified by their unique names using ||0|
WebSphere Portal's Portal Access Control (PAC) enables you to set up a very flexible authorization model. There are many different configuration options and services within WebSphere Portal that help you to tune your authorization model for better performance. This article outlined the different available options.
- Technote: Improving response time in User and Groups portlet, Resource Permissions portlet and User and Group Permissions Portlet: Describes how to improve performance of portlets that need to check access control on users or user groups.
- Technote: Delegated Administration on Users and User Groups with WebSphere Portal Access Control: Descibes the use of the
- WebSphere Portal production documentation: Provides access to all current product documentation including InfoCenters, release notes, and readmes for all releases of WebSphere Portal.
- developerWorks WebSphere Portal zone: Find more resources to help you develop portals and portlets.
Get products and technologies
- PK00044-Performance problems in user and group management portlet
- PK03477-Performance Fix: Introduces an additional performance heuristics