级别： 中级 Dieter Buehler (buehlerd@de.ibm.com), 安全架构师, IBM
Thomas Hurek ( thomas_hurek@de.ibm.com), 安全开发主管, IBM
2005 年 8 月 24 日 本文提供了基本的性能背景信息，可以帮助您使用 IBM WebSphere Portal V5 中引入的授权模型，门户访问控制（Portal Access Control，PAC）。本文描述了 PAC 配置构件、性能注意事项、应该考虑安装的各个修补程序，以及优化选项，例如，缓存层优化和设置的性能标志的最佳利用。最后，它还描述了两个门户服务，可以通过它们在门户启动过程中自动清除冗余的配置设置，以及预填充访问控制缓存。本文是为需要改善门户性能（包括登录、只读操作和管理性能）的 WebSphere 门户管理人员准备的。它解释了单个访问控制设置的好处和缺点，可以帮助您防止将来发生门户访问控制性能问题。要了解更多关于 WebSphere 门户管理和 PAC 的基本知识，请参考 WebSphere Portal InfoCenter（请参阅参考资料）。
门户访问控制概述
IBM® WebSphere® Portal Version 5.0 引入了门户访问控制授权模型，以根据角色类型和角色继承启用门户资源的实例级保护。PAC 是一个基于一系列简单规则及其对应的配置构件的通用模型，它们可以通过自由组合创建任意种类的设置——从简单的访问控制到复杂的访问控制。
PAC 模型定义的构件有：
- 受保护的资源
- 受保护资源的层次结构
- 虚拟资源
- 角色类型
- 角色
- 角色块
- 所有权
下一部分将介绍这些构件以及与其相关联的语义。
配置构件
受保护的资源 表示 PAC 保护的门户构件（如页面或 Portlet）。虚拟资源 是在门户安装过程中创建的，它构成具有对系统内每个受保护资源的引用的受保护资源层次结构 的根节点。各个资源根据其门户对象模型内的内部结构链接到该层次结构。例如，嵌套的页面作为父页面下的子页面链接，Portlet 定义作为包含它们的 Portlet 应用程序定义的子资源链接。WebSphere Portal InfoCenter 的 Security concepts => Access control 部分（请参阅参考资料）全面讨论了受保护资源层次结构的内部拓扑。
要授予用户访问特定资源（如特定页面）的权限，您需要给用户分配该资源的对应角色。每一个角色都有相关联的角色类型，代表系统中的特定工作责任。例如，Editor 角色类型表示诸如创建新的资源和修改其他用户使用的现有资源的责任。WebSphere Portal 在门户安装过程中定义了一组静态角色类型，包括（但不限于）：
- Administrator
- Security Administrator
- Delegator
- Manager
- Editor
- User
角色依赖于各个资源；因此，给定角色的特点在于对应的角色类型（定义所允许访问的级别）和受给定角色影响的一组资源。因而，您可以授予一组用户对一些资源的 Editor 特权，以及对其他一些资源的 Manager 特权。这与传统的基于角色的访问控制 (RBAC) 方法相比确实是一大改进，在基于角色的访问控制方法中，角色始终具有系统级范围。
为了免除管理员为系统中的各个资源定义单独角色的负担，PAC 支持角色继承的概念。如果授予用户的角色具有特定资源的特定类型，则自动允许用户通过角色继承同级访问受保护资源层次结构内的所有派生资源（即嵌套的子页面）。您可以使用角色块 来停用角色继承，角色块可以保护各个资源，使之免于受到角色继承的影响。角色继承是特定于角色类型的。因此，您可以在给定资源中阻止所有 Manager 角色的继承，但是仍然允许 Editor 角色继承。
PAC 支持所有权 的概念。当在 WebSphere Portal 中创建新的资源时，触发资源创建的用户身份（例如，安装新的 Portlet 的用户）将成为新资源的初始所有者。资源的所有权对所拥有的资源提供一组定义明确的特权，例如，查看、修改以及删除资源的能力。所有权可以移交给其他用户甚至其他用户组。
授权模型
每个门户用户的有效特权集都是通过联合定义的，这种联合包括两个部分，第一部分是直接分配给该用户或该用户的上一级用户组的任何角色所具有的全部特权，第二部分是所有权所具有的全部特权。（在这里，上一级用户组的含义是用户注册中心中直接或间接地将给定用户作为成员包含在内的用户组集。）这组有效的特权确切地定义了该用户可以对系统中的各个资源执行的操作。
示例：在一个示例配置中，Bob 具有 My Portal 标签的 User 角色，同时，他还是 Administrators 用户组的成员。此外，Bob 与其他用户一样，是虚拟用户组 All Authenticated Users 的隐式成员。在该配置中，Bob 将能够看到 My Portal 标签、标签下面的页面，以及 Administrator 和 All Authenticated 用户组可以访问的页面和 Portlet。
性能注意事项
PAC 模型启用了非常灵活的访问控制配置。可以通过诸如角色继承、所有权或组成员身份之类的概念授予访问权限。虽然各个选项实现相同的特权设置，但是可以对整体访问控制性能产生不同的影响。以下几部分提供了通过正确使用 PAC 管理构件实现良好性能的建议。
总体建议
PAC 依赖于配置的用户注册中心 (LDAP) 和门户配置数据库之间快速而可靠的连接，以及这些系统的良好性能。请参阅 LDAP 服务器和数据库服务器的文档，以获得关于优化这两个重要系统的信息。
PAC 建议
- 保持访问控制配置尽可能地简单。
角色块和显式角色映射的数量会影响访问控制性能。请尝试利用下列各项进行冗余显式角色分配：
示例：在以下情况中，不要给 Bob 分配资源的显式角色：
- Bob 是已经具有对资源的访问权限的用户组的成员
- Bob（或者 Bob 的某个上一级用户组）对给定资源的父资源具有相应的角色分配（这两类资源中没有角色块）
- Bob 是资源的所有者
- 将用户组的数量降到最低。
用户所属的组的数量会影响门户访问控制性能，因为用户的有效权限是通过构建联合计算的，这种联合包括两个部分，第一部分是授予用户的所有权限，第二部分是授予该用户的上一级用户组的所有权限。
-
将用户所属的不同组的数量减到最少。授予各个用户组的有效权限是基于每个用户组进行缓存的。因此，用户组的现有缓存条目可用于组的所有成员，并且不需要重新进行计算。如果每个用户都位于不同的组中，缓存将不起作用。
示例：例如，如果 Bob 已经从 Administrators 组中获取了与 Managers 组相关联的访问权限，则不要将他放在 Managers 组中。
- 避免使用嵌套的组层次结构：
从配置的用户注册中心检索嵌套的组可能是一项开销很大的操作。请尝试改用直接的组成员身份。
示例：如果您没有禁用嵌套的组，则应该检查要将 Bob 分配到的 Administrators 组是否为另一个组（如 Super Administrators 组）的成员。如果可能，则将 Bob 直接分配到该组。
- 避免在系统负载过大时进行访问控制管理。
您可以在非高峰期使用 XmlAccess 触发多个更新。只要创建或删除角色块或者角色分配，或者将新的所有者分配到资源，缓存的相应部分就必须是无效的。实际从缓存清除的信息量取决于要执行的特定操作。如果需要重新计算从缓存中清除的信息，则正在使用系统的用户将经历较长的响应时间。角色块和整个子树的删除的开销特别高，因为它们将使缓存非常大的部分无效。
示例：当大多数用户正在登录和使用门户时，请不要删除或创建页面的角色块。因为在重新构建缓存时，所有用户都将经历延迟。
- 限制使用外部访问控制。
与另一系统上的安全管理器进行的通信比在内部计算权限需要的时间长。如果确实需要外部安全管理器，请尝试仅将其用于少量资源。
示例：仅外化虚拟资源以及包含最敏感的信息的页面和 Portlet。
 |
|
优化访问控制缓存
CacheManagerService.properties 文件（位于
PortalServer/shared/app/config/services 目录中）定义了 WebSphere Portal 使用的缓存属性。不同的缓存是按它们的名称进行引用的，然后将各个属性（例如 lifetime 或 size）追加到缓存名。例如，条目
cacheinstance.com.ibm.wps.ac.ProtectedResourceCache.lifetime
标识了与名为 cacheinstance.com.ibm.wps.ac.ProtectedResourceCache 的缓存实例相关联的名为 lifetime 的属性。您可以通过调整各个缓存属性来优化相关联的缓存实例，使之满足您的特定要求：
- enabled
- 确定缓存是否启用。如果未启用缓存，则始终计算这些值。
支持的值：true 或 false
- lifetime
- 确定缓存中的条目的生存期。如果自条目添加以来的时间超过了配置的生存期，则条目是无效的。集群内的门户授权组件立即利用显式缓存无效将修改内容填充到访问控制配置中。不过，由于以下几个方面的原因，仍然推荐添加基于时间的无效。
- 在集群安装的过程中，可能会出现一些非常少见的情况，某些缓存无效消息未在每个集群节点上正确地进行处理。事实上，消息可能由于 Application Server 缓存中的争用条件而丢失。虽然发生这种情况的可能性很小，但是目前还无法完全避免。
- 当使用外部访问控制时，需要在一段时间之后使角色缓存无效，以便反映其中的角色已经外化的外部安全管理器中的修改。支持的值：秒数。（要将生存期设置为无限，请使用值 0。）
- size
- 缓存中允许的条目的数量。如果达到大小限制，则至少删除最近使用的条目，以便接受新的条目。支持的值：条目的数量。
控制缓存
您可以调整安全组件使用的这些缓存中的生存期和大小设置。
- cacheinstance.com.ibm.wps.ac.ProtectedResourceCache
- 包含受 PAC 保护的资源。这种缓存的大小与系统中活动用户访问受保护资源的数量保持合适的比例。
示例：如果在某个特定的时刻，500 个用户同时操作 20 个单独的资源（在通常情况下，每个用户都可能访问多个资源，而许多资源都由多个用户访问），则理想的缓存大小将是 10000。如果在这个场景中，活动用户的数量加倍，则理想的缓存大小也将加倍（达到 20000）。
在删除或重定向资源和修改资源状态（私有/共享）、资源所有者、外化、内化或角色块时，这种缓存是无效的。下面举一个简单的具体例子，以便您更容易理解。我不打算为每种情况举一个例子，而只说明可能确实有所不同的任何方面。
示例：Bob 使用 Manage Pages Portlet 删除了特定的门户页面，这从门户配置数据库删除了所选的页面和全部子页。因为门户页面是受门户访问控制保护的资源，所以 PortectedResourceCache 中仍然可能存在对这些删除的页面的引用。为了让门户访问控制反映最近的信息，从缓存中显式清除了 ProtectedResourceCache 中的这些引用。当门户访问控制组件下一次请求这一信息时，将有缓存丢失，并且最新的信息是从门户配置数据库中读取的。
- cacheinstance.com.ibm.wps.ac.OwnedResourcesCache
- 包含资源的所有者关系。这种缓存的大小与活动用户和组的数量乘以他们访问的不同资源类型的数量之积保持适当的比例。在删除资源、修改资源所有者、外化和用户注销的过程中，这种缓存是无效的。
- cacheinstance.com.ibm.wps.ac.RolesCache
- 包含角色实例。其大小与活动用户/组的数量乘以他们访问不同资源类型的数量之积保持适当的比例。在创建角色映射、删除角色映射、删除资源、外化、内化和用户注销的过程中，这种缓存是无效的。
- cacheinstance.com.ibm.wps.ac.RoleMappingCache
- 包含用户和组到角色的映射。其大小与活动用户/组的数量保持适当的比例。在创建角色映射、删除角色映射、删除资源、外化、内化和用户登录的过程中，这种缓存是无效的。
- cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.*, cacheinstance.com.ibm.wps.ac.ChildEntitlementsCache
- 包含用户或组对许多具有相同资源类型的资源的权限。每种资源都有专用的缓存。例如，有一种用于页面的的资源类型名为 cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.CONTENT_NODE。没有显式指定的所有资源类型都缓存在缺省缓存中。这些缓存的大小与活动用户和组的数量乘以他们访问的对缓存有效的不同资源类型的数量之积保持适当的比例。在所有修改访问控制的过程中，这种缓存都是无效的。
- cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache
- 包含用户所属的嵌套组。这种缓存是通过 WebSphere Portal V5.1.0 引入的。其大小与活动用户和组的数量和他们访问的单个虚拟门户（从 V5.1 开始）的数量保持适当的比例。在用户注销的过程中，这种缓存是无效的。
- cacheinstance.com.ibm.wps.ac.groupmanagement.GroupCache
- 包含用户所属的直接组。这种缓存是通过 WebSphere Portal V5.1.0 和 V5.0.2.2 中的 PK00044 引入的。这种缓存的大小与活动用户的数量和他们访问的单个虚拟门户（从 V5.1 开始）的数量保持适当的比例。在用户注销的过程中，这种缓存是无效的。
- cacheinstance.com.ibm.wps.ac.ChildResourcesCache
- 包含 Portal Access Control 中的资源层次结构。这种缓存的大小与系统中活动用户访问的受保护资源的数量保持适当的比例。在删除资源、更改资源的父级、修改资源状态（私有/共享）、修改资源的所有者、外化、内化和更改角色块的过程中，这种缓存是无效的。
- cacheinstance.com.ibm.wps.puma.DN_OID_Cache,
cacheinstance.com.ibm.wps.puma.OID_DN_Cache
- 包含用户和组的专有名称到内部 ObjectID 标识符的映射。这种缓存是通过 WebSphere Portal V5.0.2.2 和 V5.0.2 及 V5.0.2.1 中的 PQ90584 引入的。这种缓存的大小与活动用户和组或用于委托的用户和组的数量保持适当的比例。在删除用户和组的过程中，这种缓存是无效的。
图 1 展示了各种缓存之间的关系。小圆柱表示缓存实例，大圆柱表示数据库。绿色的缓存是门户用户管理 (PUMA) 组件的缓存，它们与门户访问控制组件的缓存密切相关。Puma 缓存来自用户注册中心的缓存信息。门户访问控制将这些缓存用于用户标识和组成员关系检索。
纵轴表示缓存聚合方向。“层”N 中的缓存实例利用低层的缓存实例来计算它们的值。
示例：在计算 Bob 的有效权限或（权利）（在 ExplicitEntitlementsCache 中缓存）时，门户访问控制组件利用 ChildResourcesCache 和 RoleMappingCache 中现有的缓存值。
图 1. 缓存与存储的相互关系
确定缓存变量值
表 1 显示了如何获取计算这些缓存的大小所需的主要变量的值。
表 1. 获得缓存变量的值的源
| 数量 | 源 |
|---|
| 受保护的资源的数量 | prot_res 表内的资源。您可以从 prot_res 运行 SQL 查询选择计数 (*) 来获取这一信息。 | | 系统中经常用户的数量 | 使用经常用户 Portlet 获取在过去 90 天内曾登录到系统的用户的数量。 | | 包含经常用户的组的数量 | 运行 XMLAccess 导出，并且只导出用户和组。检查您所知的经常登录的用户的类型，并计算他们所属的组的数量。 | | 访问的资源类型的数量 | 有大约 15 种门户资源类型（受门户访问控制的保护）和大约相同数量的文档管理资源类型（从 V5.1 开始大约有 10 种）。 |
选择性能配置选项
取决于安装情况，您可能决定使用以下配置选项中的一部分来修改门户访问控制行为。
表 2 显示了您可以在 AccessControlDataManagement.properties 文件中设置的配置参数，该文件位于
PortalServer/shared/app/config/services/ 目录中。每个属性都属于表单
accessControlDataManagement.XXX，其中 XXX 是属性。
表 2. AccessControlDataManagementService.properties
| 属性 | 语义 | 引入版本 | 性能推荐 | 缺省值 |
|---|
| enableNestedGroups | 确定直接组 (false) 或嵌套组 (true) 中的访问权限是否应该由用户继承。有关详细信息，请参见用户和组 Portlet、资源权限 Portlet 及用户和组权限 Portlet 中的 Technote Improving 响应时间。 | V5.0.0 | false | true（对于 V5.0.0） | | enableTargetResourceGroupInheritance | 确定是否使用嵌套组 (true) 或直接组 (false) 计算用户的访问权限。有关详细信息，请参见用户和组 Portlet、资源权限 Portlet 及用户和组权限 Portlet 中的 Technote Improving 响应时间。 | V5.0.0 | false | true（对于 V5.0.0）；false（从 V5.02 开始） | | enableUsersInheritance | 确定属于用户组的成员的用户是 (true) 否 (false)将从虚拟资源继承访问权限。有关详细信息，请参见 Technote: Delegated Administration on Users and User Groups with WebSphere Portal Access Control。 | PQ97770 | true | true | | cacheTimeout | 所有访问控制缓存的全局缓存超时。应该将此属性设置为高值，同时调整 CacheManagerService.properties 文件中单个缓存的生存期值。
| V5.0 – 在 V5.1.0 中被删除
| 高值（例如 1000000） | 3600 | | checkUserFirst | 确实是否应该首先检查用户 (true) 或用户所属的组 (false) 的访问权限。
| PQ93534 | 具体取决于角色设置情况。如果角色主要分配给单个用户，则设置为 true；否则，设置为 false。 | false | | loadRolesParentBased | 确定是 (true) 否 (false) 将使用用于加载角色的特殊逻辑。这种逻辑对于大量更新访问控制配置的情况特别有用。
| PQ96873 | 这种逻辑对于大量更新访问控制配置的情况特别有用（尤其是在角色分配和取消分配时）；否则，应该为 false。 | false | | doNotLoadPortletEntities | 确定是 (false) 否 (true) 在访问控制计算的过程中加载 Portlet 实体。 | PQ98480 | true | false | | useGroupCache | 确定是 (true) 否 (false) 将缓存用户所属的组。直到缓存条目超时才直接反映组层次结构中的更改。 | PK00044 – 由 accessControlGroupManagement 替代。cacheMode（对于 V5.1）。请参见以下内容。 | true | false | | checkIsLeaf | 限制没有子资源的资源缓存无效 (true)。在并发更新的情况下，这一属性应该设置为 false，因为在这些情况下可能出现死锁。
| V5.1.0.1 | true | false | | enableFastUserHasRoleHeuristic | 在完成某种资源类型的访问权限的计算之前，预计算用户的潜在访问权限。
| PK03477 | false。然而，如果用户没有访问权限，则将所有的访问权限授予组，然后将此属性设置为 true。 | false | | enableFastGroupHasRoleHeuristic | 在完成访问权限的计算之前预计算用户所属的组的潜在访问权限。如果不具有访问权限的组比具有访问权限的组多，则将此属性设置为 true。
| PK03477 | true | true | | excludeFastHasRoleTypes | 为预计算不应该包括在内的潜在访问权限指定这些资源类型。以逗号分隔的列表的形式进行指定。 | PK03477 | CONTENT_NODE, PORTLET_DEFINITION | |
表 3 显示了可以在 PACGroupManagementService.properties 文件中设置的配置参数，该文件位于
PortalServer/shared/app/config/services/
目录中。每个属性都属于表单
accessControlGroupManagement.XXX，其中 XXX 是属性。
表 3. PACGroupManagementService.properties
| 属性 | 语义 | 引入版本 | 性能推荐 | 缺省值 |
|---|
| cacheMode | 确定是 (true) 否 (false) 将缓存用户所属的组。请注意，直到用户注销或缓存超时才直接反映组层次结构中的更改。 | V5.1.0 | true | true | | cacheTimeout | 组中用户缓存的单独超时（以秒为单位），与条目的生存期无关。 | V5.1.0 | 高值 | 3600 |
更新系统服务级别
要使 WebSphere Portal PAC 的性能达到最佳状态，一定要在系统中安装针对以下 APAR 的修补程序。这些 APAR 仅用于某些版本和修补程序；它们包含在更高的版本中。请参见发行文档。
- PQ81010
- PQ84925
- PQ85787
- PQ86915
- PQ90024
- PQ90584
- PQ93534
- PQ94437
- PQ95655
- PQ96873
- PQ97751
- PQ98480
- PQ99567
- PK00044
- PK00901
- PK03477
- PK05898
- PK09159
自动清除冗余配置
您可以使用优化器（一项单独的任务）来自动清除冗余访问控制配置，例如，不必要的角色块或角色映射。可以使用 XMLAccess 请求触发该优化器。输入文件的请求标记中应该包含下列内容：
xsi:noNamespaceSchemaLocation="PacOptimization.xsd"。
清单 1 展示了一个触发优化的完整的 XMLAccess 文件，如下所示：
清单 1. 触发优化器的 XMLAccess 代码
<?xml version="1.0" encoding="UTF-8"?>
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PacOptimization.xsd">
</request>
|
在 wp_root/bin 目录中，输入下列命令（在一行中）运行 XMLAccess。使用包含上述代码段的 XML 文件的名称替换 PACOptimization.xml。
xmlaccess -user user -password password -url myhost:myport/wps/config
-in PACOptimization.xml -out result.xml
|
图 2 演示了优化器的主要功能。
Page1 具有两个子页：page2 和 page3。用户组 g1 对页面 1、2 和 3 具有 Editor 角色。Editor Inheritance 角色块出现在 page1 和 page2 之间。
优化器将删除 g1 在 page3 上的角色映射，因为 g1 已通过 page1 中的角色继承具有了相同的访问权限。如果层次结构中的其他用户或组不具有 Editor 角色，则它还将删除 page3 上的 Editor Inheritance 角色块和 Editor 角色映射。缺省情况下，优化器不会修改传播角色块。
图 2 优化任务示例
表 4 显示了可以在 AccessControlConfigService.properties 文件中设置的优化器（在 PQ97351 中引入）的其他配置选项，该文件位于
PortalServer/shared/app/config/services/ 目录中。每个属性都属于表单
accessControlConfig.XXX，其中 XXX 是属性。
表 4. AccessControlConfigService.properties
| 属性 | 语义 | 缺省值 |
|---|
| enablePrivatePageOptimization | 缺省情况下，优化器将尝试确定隐式派生的页面是否存在（隐式派生的页面在 PAC 中没有标记为私有资源）。在从 V4.x 迁移到 V5.x 后，可能出现这种情况。如果将该值设置为 false，则不会执行此逻辑，从而能够更快地进行优化。
| true | | enablePropagationBlockDeletion | 如果将该标志设置为 true，或者逻辑确定可以删除继承角色块，则传播角色块将会被删除。这可以修改某些用户/组的有效特权。
| false | | optimizationRootResource | 将优化生成资源树的根资源。可以指定虚拟资源的名称或者资源的唯一名称。缺省情况下，将优化整个树。
| | | optimizationRoleTypes | 将优化角色类型的以逗号分隔的列表。在优化过程中，将会忽略没有包含在该列表中的角色类型。缺省情况下，将优化所有的角色类型。
| |
优化启动响应时间
通过最初的用户在服务器启动后访问 WebSphere Portal，可以使用 AccessControlWarmUpService 减少访问控制请求的响应时间。在启动或预填充访问控制缓存期间，该服务分别计算与最近登录的用户或某些显式列出的用户和组相关的缓存值。
示例：如果使用缺省值，则将启用该服务，添加具有唯一名称（如 wps.My Portal）的页面，并且选择在关闭服务器之前最新登录的十个用户用于计算。将为这些用户计算对于虚拟资源（如门户或内容节点虚拟资源）和内容节点的权限。还将计算用户或用户所属的组的权限集。所有这些情况都发生在门户启动过程中。
如果某个用户在启动后访问门户，当用户是启动过程中计算的某个组的成员时，则不需要重新计算组的权限。
AccessControlWarmUpService 是在 PQ97210 和 PQ97613 中引入的。表 5 显示了可以通过修改 AccessControlWarmUpService.properties 文件设置的属性，该文件位于
PortalServer/shared/app/config/services/ 目录中。每一个属性都属于表单
accessControlConfig.XXX，其中 XXX 是属性。
表 5. AccessControlWarmUpService.properties
| 属性 | 逻辑 | 缺省值 |
|---|
| enabled | 确定是 (true) 否 (false) 启用 AccessControlWarmUpService。
| false | | numberOfMostRecentUsers | 指定用于预填充缓存的最新登录的用户的数量。
| 10 | | numberOfUsers | 如果将该属性设置为值 > 0，则可以通过使用 user.<number>=< Distinguished Name of the user> 标记的专有名称在文件中显式指定某组用户（最近的用户除外）。
| 0 | | numberOfGroups | 如果将该属性设置为值 > 0，则可以通过使用
group.<number>=< Distinguished Name of the group> 标记的专有名称在文件中显式指定某组用户组（最近的用户除外）。
| 0 | | numberOfUniquenames | 缺省情况下，仅计算对于虚拟资源的权限。如果将该属性设置为值 > 0，则对于在文件中通过使用 uniquename.<number>=< Unique Name of the resource> 标记的唯一名称确定的某组资源，还将计算对于这组资源的权限。 | 0 |
参考资料 学习
获得产品和技术
作者简介 | 
| | Dieter Buehler 博士在德国图宾根大学 (University of Tuebingen) 学习计算机科学（于 1998 年以优异的成绩毕业）。三年以后他获得了博士学位。Dieter 于 2002 年加入 IBM，并且从 2004 年 4 月起开始担任 WebSphere Portal 安全架构师。 |
| 
| | Thomas Hurek 是德国 IBM 开发实验室的一名软件工程师。在 WebSphere Portal 开发团队中，他负责安全性和虚拟门户开发。 |
对本文的评价
| 
