Performance tuning of Portal Access Control

This article provides portal administrators with essential performance background information so you can improve your portal's performance, including login, read-only operation, and administration performance. You learn how to prevent future portal access control performance issues by making the best use of Portal Access Control (PAC), an authorization model introduced in IBM WebSphere Portal V5. You learn about the PAC configuration artifacts, performance considerations, individual fixes you should consider installing, and the benefits and drawbacks of individual access tuning options such as tuning the caching layers, and the best use of performance flags for your setup. You also see how to configure two portal services so they automatically clean up redundant configuration settings and pre-fill access control caches during portal start-up. To learn more about WebSphere Portal administration and PAC basics refer to the WebSphere Portal InfoCenter (see Resources).

Dieter Buehler (buehlerd@de.ibm.com), WebSphere Portal Security Architect, IBM

Dieter Buehler photoDr. Dieter Buehler studied computer science at the University of Tuebingen in Germany (passed with distinction 1998). He obtained the title Dr. rer. nat three years later. Dieter entered IBM in 2002 and has been a WebSphere Portal Security Architect since April 2004.



Thomas Hurek ( thomas_hurek@de.ibm.com), Security Lead Developer, IBM

Thomas Hurek photoThomas Hurek is a software engineer at the German IBM development lab. He is responsible for Security and Virtual Portal development in the WebSphere Portal development team.


developerWorks Contributing author
        level

24 August 2005

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
  • Role block
  • Ownership

The next section introduces these artifacts and their associated semantics.

Configuration artifacts

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:

  • Administrator
  • Security Administrator
  • Delegator
  • Manager
  • Editor
  • User

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.

Authorization model

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.


Performance considerations

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.

General recommendations

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.

PAC recommendations

  1. 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
  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

The 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 cacheinstance.com.ibm.wps.ac.ProtectedResourceCache.lifetime identifies a property named lifetime associated with the cache instance named cacheinstance.com.ibm.wps.ac.ProtectedResourceCache You can adjust individual cache properties to tune the associated cache instances to your specific needs:

enabled
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

lifetime
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.)
size
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

Control caches

You can adjust the lifetime and size settings on these caches, which are used by the security components.

cacheinstance.com.ibm.wps.ac.ProtectedResourceCache
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.

cacheinstance.com.ibm.wps.ac.OwnedResourcesCache
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.
cacheinstance.com.ibm.wps.ac.RolesCache
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.
cacheinstance.com.ibm.wps.ac.RoleMappingCache
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.
cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache
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.
cacheinstance.com.ibm.wps.ac.groupmanagement.GroupCache
Contains the direct groups to which a user blongs. This cache was introduced with WebSphere Portal V5.1.0, and PK00044 on V5.0.2.2. 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.
cacheinstance.com.ibm.wps.ac.ChildResourcesCache
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 V5.0.2.2 and PQ90584 on V5.0.2 and V5.0.2.1. 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
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.

Table 1. Sources for obtaining values for cache variables
Number of ...Source
Protected resourcesResources within the prot_res table. You could run an SQL query select count (*) from prot_res to get this information.
Frequent users in your systemUse the Frequent Users portlet to get the number of users that logged on to your system in the last 90 days
Groups with frequent usersRun 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 typesThere 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 PortalServer/shared/app/config/services/ directory. Each property is of the form accessControlDataManagement.XXX, where XXX is the Property.

Table 2. AccessControlDataManagementService.properties
PropertySemanticsIntroducedPerformance recommendationDefault
enableNestedGroupsDetermines 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.0falsetrue with V5.0.0
enableTargetResourceGroupInheritanceDetermines 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.0false true with V5.0.0; false starting V5.02
enableUsersInheritanceDetermines 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.PQ97770truetrue
cacheTimeoutGlobal 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
checkUserFirstDetermines if the access rights shall be checked first for the user (true) or the groups the user is member of (false). PQ93534Depends upon the role setup. If roles are assigned primarily to individual users, then set to true; otherwise, set to false.false
loadRolesParentBasedDetermines 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. PQ96873This logic especially makes useful in scenarios with many updates of the access control configuration (especially role assignments and unassignments), otherwise, should be false.false
doNotLoadPortletEntitiesDetermines whether Portlet Entities are loaded during access control computations (false) or not (true). PQ98480truefalse
useGroupCacheDetermines 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) truefalse
checkIsLeafLimits 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. V5.1.0.1truefalse
enableFastUserHasRoleHeuristicPrecomputes potential access rights of a user before the complete computation of the access rights for a ResourceType. PK03477false. However, if the users have no access rights, but all access rights are granted to the groups, then set this property to true.false
enableFastGroupHasRoleHeuristicPrecomputes 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. PK03477truetrue
excludeFastHasRoleTypesSpecifies those ResourceTypes for which precomputation of potential access rights should not be included. Specify as a comma-separated list. PK03477CONTENT_NODE, PORTLET_DEFINITIONAll 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 PortalServer/shared/app/config/services/ directory. Each property is of the form accessControlGroupManagement.XXX, where XXX is the Property.

Table 3. PACGroupManagementService.properties
PropertySemanticsIntroducedPerformance recommendationDefault
cacheModeDetermines 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.0truetrue
cacheTimeoutSeparate timeout in seconds for the user-in-group caches independent of the lifetime of the entries. V5.1.0high value3600

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.

  • PQ81010
  • PQ84925
  • PQ85787
  • PQ86915
  • PQ90024
  • PQ90584
  • PQ93534
  • PQ94437
  • PQ95655
  • PQ96873
  • PQ97751
  • PQ98480
  • PQ99567
  • PK00044
  • PK00901
  • PK03477
  • PK05898
  • PK09159

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: xsi:noNamespaceSchemaLocation="PacOptimization.xsd".

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
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 PortalServer/shared/app/config/services/ directory. Each property is of the form accessControlConfig.XXX, where XXX is the Property.

Table 4. AccessControlConfigService.properties
PropertySemanticsDefault
enablePrivatePageOptimizationBy 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
enablePropagationBlockDeletionIf 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
optimizationRootResourceThe 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.
optimizationRoleTypesComma 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 PortalServer/shared/app/config/services/ directory. Each property is of the form accessControlConfig.XXX, where XXX is the Property.

Table 5. AccessControlWarmUpService.properties
PropertyLogicDefault
enabledDetermines if the AccessControlWarmUpService is enabled (true) or not (false). false
numberOfMostRecentUsersSpecifies the number of most recently logged-in users to be used for pre-filling the caches. 10
numberOfUsersIf this property is set to a value > 0, a certain set of users can be specified explicitly with their Distinguished Names using user.<number>=< Distinguished Name of the user> tags in the file in addition to the recent users. 0
numberOfGroupsIf this property is set to a value > 0, a certain set of groups can be specified explicitly with their Distinguished Names using group.<number>=< Distinguished Name of the group> tags in the file in addition to the recent users. 0
numberOfUniquenamesBy 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 uniquename.<number>=< Unique Name of the resource> tags in the file the permissions will be computed as well.0

Conclusionl

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.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=92567
ArticleTitle=Performance tuning of Portal Access Control
publish-date=08242005