In Portal, all artifacts have access control on them. Access control is a long subject, but in short there are several roles (i.e. User, Privileged User, Editor, Manager, etc). For each of these roles, there can be either Portal defined groups (e.g. Anonymous Users or All Authenticated Users) as well as Users and Groups from the Identity Store (LDAP or File Repository). Having your User or Group in a particular role allows you the ability to do certain prescribed operations on that artifact. The exact operations are lengthy and beyond the scope of this article. However, the Portal InfoCenter has details regarding this. One can start with this page to see the details of the access control rights on resources.
Access Control Lists are maintained in the database (e.g. DB2, Oracle). When creating these ACLs, one or more table rows need to be created. However, if one does not carefully take into account inheritance and propagation of ACLs from the parents, it is possible to create significantly more rows in the access control table than are needed. For that reason, Portal has created an "Optimizer" task which will "clean up" the PAC tables depending on the ACL hierarchies. Optimizing the roles of the PAC tables in Portal can potentially improve the performance of the Portal a great deal.
Unfortunately, this optimization task is undocumented in the Portal InfoCenter. Here are the relevant details.
Running the PAC Optimizer is done via an xmlaccess task. Below is an example of the input required to run the optimizer:
<?xml version="1.0" encoding="UTF-8"?>
There are two parameters of note in this xmlaccess input deck. The first is "report-only". Set to "true" if you want no changes actually made but want to see the number of changes required to the PAC tables. Set this to "false" if you want the optimizer to actually make the changes to the database when it finds optimizations to be done.
The "rootResource" parameter controls the root element of the tree of resources to consider. This parameter can be a UUID ID as shown in the example. This example happens to be a WCM SIteArea. Thus, only ACLs related to WCM documents in this site area will be optimized with respect to their ACLs.
This parameter could also be a custom unique name like "wps.content.root" which is the highest page in the Portal page hierarchy. The highest level in the total Portal hierarchy is "wps.PORTAL". This virtual resource is the root of all Portal elements. Having no root resource is the same as specifying "wps.PORTAL" as the root resource. Not that doing this could take a significant amount of time. It is advised to start small and specify only a subtree of resources to begin with.
In addition to the xmlaccess input deck, there are some parameters which control the PAC Optimizer. These are located in the WebSphere Application Server Resource Environment Provider named "WP AccessControlService" In the "Custom properties" one can set the following:
accessControlConfig.enablePropagationBlockDeletion, boolean, default "false": If "true", allows the Optimizer to remove propagation blocks for a resource if all the children have the same Principals (Users and Groups) in a role as the parent but the parent has blocked propagation
accessControlConfig.enablePrivatePageOptimization, boolean, default "true": If "true", allows the Optimizer to optimize ACLs for private pages that users might have created.
At this point, the main question to ask is when does running the PAC Optimizer make sense. While there are no hard and fast rules, the obvious answer is that it makes sense when excessive access control has been placed on individual objects and NOT enough use of inheritance and propagation is used. And, in general, roles should be given to groups of users (e.g. LDAP groups and NOT individuals). The key to all of this lies in the count of rows in selected PAC tables in the RELEASE and JCR Portal databases. Note that actual database and schema names are customer implementation dependent. I'll use the generic names here.
For example, if running "SELECT COUNT(*) FROM JCR.LNK_USER_ROLE" exceeds some moderately high threshold like 1000, then running the optimizer makes sense. This count identifies users and/or groups who have individual roles on JCR (e.g. WCM) content. Likewise, running "SELECT COUNT(*) FROM RELEASE.LNK_USER_ROLE" gives one a sense of how many users and groups have roles on RELEASE objects (like page, labels and just about any non-WCM resource in Portal that has ACLs). Again, if that number is "high", then perhaps one is not taking sufficient use of inheritance and propagation in the RELEASE hierarchy.