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" is you want the optimizer to actually make the changes it finds that need 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.
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 is 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.