多个安全域

安全域为何有用

WebSphere 安全域提供了两个主要优点:

在先前版本的 WebSphere Application Server中，所有管理应用程序和用户应用程序都共享大部分安全性属性。 缺省情况下， WebSphere Application Server 中的所有管理应用程序和用户应用程序都使用全局安全性属性。 例如，对于单元中的每个应用程序，都会使用全局安全性中定义的用户注册表来对用户进行认证。

但是，在此发行版的 WebSphere Application Server中，可以将多个安全性属性用于非全局安全性属性的用户应用程序，为那些必须不同的安全性属性创建安全域，并将它们与托管这些用户应用程序的服务器和集群相关联。 还可以使安全域与单元相关联。 如果单元中的所有用户应用程序先前都没有与其相关联的域，那么它们会使用此安全域。 但是，管理应用程序（例如管理控制台、命名资源和 MBean）仍然需要使用全局安全性属性。

如果在 WebSphere Application Server的先前发行版中使用了服务器级别安全性，那么现在应该使用多个安全域，因为它们更灵活且更易于配置。

本发行版不推荐使用服务器级别的安全性。 有关更多信息，请参阅 全局安全性和安全域之间的关系 。

全局安全性与安全域之间的关系

全局安全性适用于所有管理功能和用户应用程序的缺省安全性配置。 可以使用安全域来为用户应用程序定义已定制的配置。

必须先定义全局安全性配置，然后才能创建安全域。 所有管理应用程序（例如管理控制台、命名资源和 MBean）都使用全局安全性配置。 如果未配置任何安全域，那么所有这些应用程序都使用全局安全性配置中的信息。 诸如 Enterprise JavaBeans (EJB) ， Servlet 和管理应用程序之类的用户应用程序使用相同的安全性配置。

创建安全域并使其与某个作用域相关联时，仅该作用域中的用户应用程序使用安全域中定义的安全性属性。 该作用域中的管理应用程序以及命名操作使用全局安全性配置。 请在域级别上定义需要与全局级别上安全性属性不同的安全性属性。 如果该信息是公共信息，那么不必在安全域中重复定义此信息。 将从全局配置中获取该域中缺少的任何属性。 全局安全性配置数据存储在 $WAS_HOME/profiles/$ProfileName/cells/$CellName 目录中的 security.xml 文件中。

下图提供了多安全域的一个示例，其中，单元、服务器和集群与不同的安全域相关联。 如图所示，服务器 S1.1 中的用户应用程序以及集群中的用户应用程序分别使用 Domain2 和 Domain3 中定义的安全性属性（其原因在于，这些作用域与这些域相关联）。 服务器 S2.2 未与任何域相关联。 因此，在缺省情况下，S2.2 中的用户应用程序将使用与该单元相关联的域 (Domain1)。 在域级别不存在的安全性属性将从全局配置中获取。

下图显示可以在全局安全性配置中定义并可以在域级别进行覆盖的各种高级别安全性属性。

安全域的内容

安全域由两个配置文件表示。 其中一个配置文件包含该安全域中配置的属性的列表。 另一个配置文件包含使用了该安全域的作用域。 安全域信息存储在 $WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName 目录中。 对于所配置的每个安全域，都将创建一个其中包含两个文件的 $SecurityDomainName 目录：security-domain.xml 文件包含为该安全域配置的安全性属性的列表，而 security-domain-map.xml 文件包含使用了该安全域的作用域。

下图指示与主安全域相关的文件的位置以及那些文件的内容。

创建安全域

使用管理控制台任务或脚本编制命令来创建安全域。 在管理控制台中，通过单击 安全性 > 安全域来访问安全域。 每个管理控制台面板都提供了帮助。

要获取管理控制台任务和脚本编制命令的完整列表，请参阅本文档末尾的“相关任务”中的链接。

在创建安全域时，您必须为该域提供唯一的名称、要为该安全域配置的安全性属性以及需要使用该安全域的作用域。 完成配置后，必须将使用该安全域的服务器重新启动。 这样，那些作用域中的用户应用程序将使用该安全域中定义的属性。 任何未在域级别进行配置的属性都将从全局安全性配置中获取。 作用域中的管理应用程序和命名操作始终使用全局安全性配置中的安全性属性。 您必须主动地管理这些属性。

任何新的安全域属性都必须与分配给该域的用户应用程序所继承的那些全局安全性属性兼容。

除了对于 JAAS 和定制特性外，如果为域定制了全局属性，那么用户应用程序不再使用这些全局属性。

管理控制台中的“安全域”面板使您能够分配资源以及为域选择适当的安全性属性。 此面板显示了全局配置中的关键安全性属性；必要时，您可以决定在域级别覆盖这些属性。 在域级别配置并保存属性之后，此面板上的摘要值将显示为该域定制的值（标有黑色文本“定制”）。

作用域（服务器、集群、服务集成总线或单元）只能与一个域相关联。 例如，不能定义两个都限于单元范围的域。 但是，可以在同一个安全域中定义多个作用域。 例如，可以将一个域的作用域限定为 Server1 以及只存在于单元中的 Server2。

安全域面板上“已指定的作用域”部分显示了两个视图：其中一个视图使您能够选择作用域并将其指定到域，另一个视图使您能够查看当前已指定的作用域的列表。 为了方便起见，您还可以灵活地将所有安全性属性从现有的安全域或全局配置复制到新的安全域，然后只修改那些必须有所不同的属性。 您仍必须使作用域与这些复制的域相关联。

另外，脚本编制命令也使您能够创建、复制和修改安全域。 在创建域之后，必须运行适当的命令以使安全性属性和作用域与该域相关联。

为安全域配置属性

可以在 WebSphere Application Server V 9.0 中的域级别配置的安全性属性包括:

管理控制台中的安全域面板显示所有这些安全性属性。

在域级别无法覆盖的其他一些众所周知的属性包括 Kerberos， Audit ， Web Single Sign-on (SSO) 和 Tivoli ® Access Manager (TAM)。 安全套接字层 (SSL) 属性已支持不同的作用域，但它不是域配置的一部分。 对于域级别上不受支持的所有属性，域中的用户应用程序会从全局级别共享其配置。

任何新的安全域属性都必须与分配给该域的用户应用程序所继承的那些全局安全性属性兼容。 您必须主动地管理这些属性。 例如，如果在域级别上仅定制 JAAS 配置，那么必须确保它使用在全局级别上配置的用户注册表（如果在域级别上未定制该用户注册表）。

除了对于 JAAS 和定制特性外，如果为域定制了全局属性，那么用户应用程序不再使用这些全局属性。

Tivoli Access Manager 客户机运行时用于通过联系 TAM 服务器来提供认证 (由 TrustAssociation拦截器和 PDLoginModule使用) 和授权 (用于 JACC)。 单元中的所有服务器仅共享一个 Tivoli Access Manager 运行时。 请阅读 Tivoli Access Manager JACC 提供程序配置主题以获取更多信息。

您不能在安全域级别具有不同的 Tivoli Access Manager 配置，以覆盖单元级别的配置。 但是，您可以在安全域级别在一定程度上指定信任关联拦截器 (TAI) 和 JACC 配置。 例如，可以使用另一 TAI 或另一授权提供程序。 由于 TAM 服务器连接只能在全局级别定义，因此您可以具有多个在安全域级别定义并配置的 TAI。 其中某些 TAI 可能不使用 TAM 用户资源库，而另一些使用。 不需要连接到 TAM 的那些 TAI 也连接到全局定义的 TAM 服务器。 对于授权，同样可以具有多个在域级别配置的外部授权提供程序。 但是，如果其中任何外部授权提供程序需要连接到 TAM，那么它们会结束与唯一全局配置的 TAM 服务器的通话。

使作用域与安全域相关联

当安全域与不是集群的一部分的服务器相关联时，该服务器中的所有用户应用程序都使用该安全域中的属性。 会从全局安全性配置中获取任何缺少的安全性属性。 如果服务器是集群的一部分，那么可以使安全域与集群相关联，但不使安全域与该集群中各个成员相关联。 这样，安全行为在所有这些集群成员之间保持一致。

如果服务器要作为集群的一部分，请首先创建集群，然后使安全域与它相关联。 在服务器成为集群成员之前，您可能已使域与该服务器相关联。 如果情况如此，那么即使该域直接与该服务器相关联，安全性运行时代码也不会查看该域。 当服务器是集群成员时，安全性运行时会忽略直接与该服务器相关联的任何安全域。 从安全域中除去服务器作用域并改为使集群作用域与该安全域相关联。

还可以使安全域与单元相关联。 当您想要将 WebSphere Application Server 中的所有用户应用程序与安全域相关联时，通常会执行此操作。 在此情况下，所有管理应用程序和命名操作都使用全局安全性配置，而所有用户应用程序都使用域级别配置。 如果要为管理应用程序和用户应用程序分离安全性配置信息，那么这是所需的全部。

如果您具有混合版本环境，或者计划将来具有混合版本环境，并且要在单元级别关联安全域，请阅读 混合版本环境中的安全域 以获取更多信息。

如果您所在的基本概要文件服务器已定义它自己的安全域，且随后联合到 Deployment Manager，请使服务器作用域（而不是单元作用域）与该安全域相关联。 当您联合该节点时，安全域信息会被传播至该 Deployment Manager。 如果单元作用域与该安全域相关联，那么 Network Deployment 配置使用此安全性配置，这可能影响现有应用程序。 联合期间，单元作用域会被更改为正在联合的服务器作用域。 如果服务器作用域与该安全域相关联，那么在联合之后，仅该服务器使用该安全域。 其他服务器和集群中的其他应用程序不受影响。 但是，如果已向管理代理程序进程注册此基本概要文件服务器，那么当要基本概要文件中所有服务器都将同一安全域用于它们的所有用户应用程序时，可以使单元作用域与该安全域相关联。 有关更多信息，请参阅 联合具有安全域的节点 。

您可以使安全域在单元级别上相关联，并且还可以使其他安全域与各种集群或各台服务器（不是任何集群的一部分）相关联。 在此情况下，安全性运行时会首先检查是否有任何安全域与服务器或集群相关联。 如果存在与服务器或集群相关联的安全域，那么会将该安全域中定义的安全性属性用于该服务器或集群中的所有应用程序。 会从全局安全性配置但不是从与单元相关联的域配置中获取此服务器或集群域中缺少的任何安全性属性。

如果该服务器或集群未定义它自己的域，那么安全性运行时代码会使用与单元相关联的域（如果定义了一个域）中的安全性属性。 会从全局安全性配置继承单元域中缺少的任何安全性属性。

旧服务器级安全性与新安全域之间的关系

在 WebSphere Application Server的先前发行版中，可以在服务器级别关联一组小型安全性属性。 这些属性已由服务器级别上的所有应用程序使用。 先前配置安全性属性的方法在 WebSphere Application Server 7.0中已不推荐使用，并且将在将来的发行版中移除。

现在，您应该从 WebSphere Application Server 7.0开始使用新的安全域支持，因为这些安全域更易于管理，更灵活。 例如，在先前版本的 WebSphere Application Server中，必须通过为集群中的每个服务器配置相同的安全性属性来手动将相同的安全性配置与所有集群成员相关联。

当脚本兼容性方式为 false (-scriptCompatibility="false") 时，迁移工具会将现有服务器级别的安全性配置信息迁移到新的安全域配置。 如果服务器不是集群的一部分，那么会为每台服务器的安全性配置都创建新的安全域。 如果服务器是集群的一部分，那么安全域与该集群相关联，但不与该集群中所有服务器相关联。 在这两种情况下，会将前发行版中在服务器级别上配置的所有安全性属性都迁移到新的安全域配置，并且会将相应的作用域分配给安全域。

如果脚本兼容性方式设置为 true，那么不会将服务器级别的安全性配置迁移到新的安全域配置。 会迁移旧服务器安全性配置，但不进行任何更改。 即使安全域直接或间接与服务器相关联，安全性运行时也会检测旧安全性配置是否存在并使用该信息。 如果脚本兼容性方式设置为 true，请从服务器级别除去安全性配置，然后创建具有同一组安全性属性的安全域。

安全性运行时和应用程序如何使用域级安全性属性

本节描述安全性运行时如何使用域级别上的各个属性以及这如何影响用户应用程序安全性。 因为还在全局级别上定义了所有这些安全性属性，所以可以从其他位置获取有关这些属性的更多信息。 就本节而言，强调的是域级别的行为。

使用安全域时的客户机和应用程序安全性编程模型

作为访问 EJB 的客户机的 Java 客户机或应用程序通常首先执行命名查找。 管理应用程序和用户应用程序所使用的命名资源都被视为管理资源。 它受全局安全性配置信息保护。 在多域设置中，全局安全性使用一个域 (用户注册表) ，而域使用另一个域， Java 客户机必须向两个不同的域进行认证。 全局安全性配置中的领域要求进行第一次认证才能确保命名操作成功，而访问使用了另一个领域的 EJB 则要求进行第二次认证。

CosNamingRead 角色保护所有命名读操作。 此角色通常分配给 Everyone 特殊主体集。 这意味着，任何用户（无论是否有效）都可以在名称空间中执行查找。 定义多域后，如果 CosNamingRead 角色具有 Everyone 特殊主体集，那么客户端中的安全性运行时代码将不会提示您进行登录。 而是，它将使用 UNAUTHENTICATED 主体集来访问命名操作。 命名查找操作完成后，当客户机尝试访问该 EJB 时，它将接收到一个登录面板，此面板指示了该 EJB 应用程序当前所使用的领域（即，在该域中使用的领域）。 接着，客户机将提供适合于该领域的用户凭证，从而能够访问该 EJB。 此逻辑适用于登录源的所有变体，包括 properties 和 stdin，而不仅仅是在登录源设置为 prompt 时才适用。

如果从 CosNamingRead 角色中除去了 Everyone 特殊主体集，那么您将接收到两次提示。 如果登录源为 properties，那么可以取消注释 $WAS_HOME/profiles/$ProfileName/properties/sas.client.props 文件中的 com.ibm.CORBA.loginRealm 属性，并使用 "|" 作为分隔符来添加相应的域。 另外，还必须分别在 com.ibm.CORBA.loginUserid 和 com.ibm.CORBA.loginPassword 属性中输入相应的用户和密码。 在 Java 客户机代码中使用程序化登录时，必须使用不同的用户凭证进行两次认证; 一次是在对 EJB 执行命名查找之前 (用户应该在全局域中) ，另一次是在调用 EJB 中的任何方法之前 (用户应该在 EJB 域中)。

未引用 z/OS 安全服务器中定义的 CosNaming读角色，以确定是否在多安全域环境中保护命名读操作，即使启用了 SAF 授权也是如此。 而是，将使用 admin-authz.xml 文件中的设置。 另外，您可以使用定制属性 com.ibm.security.multiDomain.setNamingReadUnprotected 来控制命名读操作是否受保护。 此属性将覆盖对 CosNamingRead 角色所进行的任何分配，而不考虑所使用的授权提供程序。

通常，当 Java 客户机需要向多个不同的域进行认证时，它必须提供所有这些域的凭证信息。 如果登录源是 prompt 或 stdin，那么它将被提示登录多次，即，针对每个领域进行一次登录。 如果登录源设置为 properties，那么将使用 sas.client.props 文件（或任何相关文件）中的适当属性向不同的领域进行认证。

在某些情况下，客户机可能会对同一个领域执行多次调用。 例如， Java 客户机可以使用 realm1 访问资源，然后使用 realm2访问资源，然后返回以再次访问 realm1 中的资源。 在这种情况下，此客户机将被提示登录三次；第一次针对 realm1 进行登录，第二次针对 realm2 进行登录，第三次再次针对 realm1 进行登录。

缺省情况下，客户端代码不会对用于登录到领域的主体集进行高速缓存。 如果您有此方案，并且希望客户机根据域对主题进行高速缓存，请在 sas.client.props 文件中将 com.ibm.CSI.isRealmSubjectLookupEnabled 属性设置为 true 。 如果设置了 com.ibm.CSI.isRealmSubjectLookupEnabled 属性，那么客户机代码会基于域名对该主体集进行高速缓存。 下次 Java 客户机需要向此域进行认证时，将找到高速缓存以获取主题，并且不会提示客户机。 此外，当设置了 com.ibm.CSI.isRealmSubjectLookupEnabled 属性时，会将第一次登录的同一主体集用于后续登录。 如果需要更改主体集信息，那么不应设置此属性。

如果客户机正在执行程序化登录，那么它可以传递领域以及进行认证所需的用户和密码。 在这种情况下，当 com.ibm.CORBA.validateBasicAuth 属性在 sas.client.props 文件中设置为 true (缺省值) 时，将使用与域名匹配的注册表进行登录。 该领域在执行认证的进程中必须受支持。

使用 WSLogin JAAS 配置时，还必须在 $WAS_HOME/profiles/$ProfileName/properties 中的 wsjaas_client.config 文件中设置 use_realm_callback 选项，以便将域名传递到回调处理程序。 如果要对名称服务器指定另一个提供程序 URL，请设置 use_appcontext_callback 选项并通过散列映射将提供程序 URL 属性传递给 WSLogin。

If you do not know the realm name, use <default> as the realm name. 在这种情况下，将向应用程序领域执行认证。 如果未对命名读操作分配 Everyone 特殊主体集，那么您必须提供管理应用程序所使用的领域（全局安全性配置中使用的注册表）以及该注册表中的相应用户和密码信息才能确保查找操作成功。

After the lookup operation succeeds, perform another programmatic login by providing the application realm (or <default>) and the user and password information for the appropriate user in the registry that is used by the application. 这类似于登录源为 prompt 的情况。 您必须执行两次认证，第一次针对全局安全性配置所使用的注册表进行认证（为了执行命名查找操作），第二次针对应用程序所使用的注册表进行认证（为了访问 EJB）。

If com.ibm.CORBA.validateBasicAuth is set to 假 in the $WAS_HOME/profiles/$ProfileName/properties/sas.client.props file then the programmatic login can use <default> as the realm name for both the lookup and the EJB operations. 仅当在服务器端访问资源时，才会进行实际的认证，在这种情况下，将根据所访问的资源来计算领域。

从 WebSphere Application Version 7.0 开始的新安全域支持不会更改当前应用程序安全编程模型。 但是，它更为灵活并提供了更多功能，例如：

多域配置中的应用程序部署

在多域设置中部署应用程序时，应该将该应用程序中的所有模块都安装在属于同一个安全域的服务器或集群中。 否则，根据这些安全域中配置的安全性属性不同，可能会出现不一致的行为。 例如，如果这些域包含不同的用户注册表，那么用户和组信息可能不同，这可能导致访问模块时出现不一致的行为。 另一个示例是，安全域之间的 JAAS 数据有所不同。 在这种情况下，将无法从该应用程序中的所有模块中访问 JAAS 配置。 在处理用户注册表、JAAS 登录配置、J2C 认证数据和授权之类的属性时，安全性运行时代码和命令任务依赖于一个域与应用程序相关联。

在大多数情况下，跨不同的域部署应用程序时，应用程序部署工作将失败。 但是，由于在 WebSphere Application Server 的先前发行版中仅在服务器级别支持几个属性时可以执行此操作，因此部署工具将首先检查在域中配置的属性。 如果域中的属性与前发行版中支持的属性相同，那么管理控制台会请求确认，以确保您要在多个安全域之间部署应用程序模块。 除非绝对要求在不同域之间部署应用程序，否则，请停止部署并选择同一安全域中的服务器和集群。

跨领域通信

当应用程序使用 RMI/IIOP 协议进行通信，并且认证机制为 LTPA 时，将在所涉及的服务器之间传递 LTPA 令牌。 LTPA 令牌包含登录到前端应用程序的用户的领域限定 uniqueId（也称为 accessId）。 下游服务器接收到此令牌时，它将尝试对此令牌进行解密。 如果在两台服务器之间共享 LTPA 密钥，那么解密将成功，并且将从此令牌中获取用户的 accessId。 系统将根据应用程序所使用的当前领域来检查 accessId 中的领域。 如果领域匹配，那么 LTPA 令牌验证操作将成功，接着将进行授权。 如果领域不匹配，那么令牌验证将失败，这是因为无法在应用程序的当前领域中验证来自外来领域的用户。 如果使用 RMI/IIOP 和 LTPA 认证机制时应用程序相互应该不会进行通信，那么您不必执行进一步的操作。

如果您希望跨领域通信在使用 RMI/IIOP 和 LTPA 令牌时成功，那么必须先在所涉及的领域之间为入站通信和出站通信建立信任关系。

对于发起请求的服务器，它的领域必须包含它可以信任的领域（要将令牌发送到这些领域）。 这称为出站可信领域。 对于接收请求的服务器，它的领域需要信任它可以从中接收 LTPA 令牌的领域。 这称为入站可信领域。

可使用 addTrustedRealms 命令并将-communicationType 选项设置为 Outbound来建立出站可信领域。 还可以在管理控制台中通过单击 CSIv2 outbound communications 面板上的 Trusted authentication realms - outbound 来建立此功能。

可以使用同一 addTrustedRealms 命令任务 (将-communicationType 选项设置为 inbound) 来建立入站可信领域。 另外，也可以使用管理控制台来建立此领域。

本节中稍后的图显示使用不同用户域（注册表）的应用程序之间通过 RMI/IIOP 进行的通信。 在此示例中，应用程序 app1（例如，servlet）配置为使用 realm1 用户注册表。 将应用程序 app2（例如，这是一个 EJB）配置为使用 realm2 用户注册表。 用户 user1 最初登录到 app1 中的 Servlet，该 Servlet 接着尝试访问 app2 中的 EJB。 必须设置下列各项：

当 app2 接收到包含 user1 的 accessId 的 LTPA 令牌时，它将对该令牌进行解密。 这两个服务器共享相同的 LTPA 密钥。 然后，LTPA 令牌确保外来领域是可信领域，并且将根据 user1 的 accessId 来执行授权。 如果未禁用安全性属性传播功能，那么 user1 的组信息也将传播到 app2。 如果授权表包含组信息，那么这些组可以用于执行授权检查。 可以使特殊主体集 AllAuthenticatedInTrustedRealms 与角色相关联，而不是将各个用户和组添加至授权表。

如果前面示例中的应用程序部署在不同的单元中，那么您必须执行下列操作：

在领域之间建立信任关系后，当服务器接收到 LTPA 令牌并对该令牌进行解密时，它将进行检查以确定该外来领域是否在其入站可信领域列表中。 如果该外来领域可信，那么认证成功。 但是，由于它是外来领域，因此不会搜索用户注册表以收集关于该用户的信息。 无论该 LTPA 令牌包含什么信息，均使用该信息对该用户进行授权。

LTPA 令牌中包含的信息只有用户的唯一标识。 用户的这个唯一标识应该存在于此应用程序的授权表中。 如果确实如此，那么授权将成功。 但是，如果已启用属性传播功能，那么将把此用户的其他授权属性（此用户所属的组）从始发服务器发送到接收服务器。 这些附加的属性用于进行访问权决策。 如果组信息存在于传播令牌中，那么进行授权决策时，将使用该信息。

如上所述，关于可信领域中的用户或组的信息应该存在于接收应用程序的授权表中。 具体而言，这些用户或组的 accessId 应该存在于应用程序的绑定文件中。 部署应用程序时，情况必须如此。 在管理控制台中将应用程序部署到某个域时，您可以将其任何可信领域中的用户和组的 accessId 添加到授权表中。

还可以选择使特殊主体集 AllAuthenticatedInTrustedRealms 与角色相关联，而不是添加各个用户和组。 这与当前受支持的特殊主体集 AllAuthenticated 类似。 差别在于，特殊主体集 AllAuthenticated 是指与应用程序在同一域中的用户，而特殊主体集 AllAuthenticatedInTrustedRealms 适用于可信域以及应用程序的域中的所有用户。

您可以使用 $AdminApp 安装脚本来关联 accessId。 由于 accessId 采用唯一格式，因此，请使用命令任务 listRegistryUsers 并将 displayAccessIds 设置为 true。 如果在此字段中输入了无效的名称或格式，那么授权将失败。

由于 Deployment Manager 有权访问所有域中的所有用户注册表配置，因此它将获取可信领域中的用户和组信息。 但是，在某些情况下，无法获取用户和组信息。

例如，如果在外部节点上主管的服务器正在使用 localOS 作为它的域的注册表，那么除非 Deployment Manager 正在同一个操作系统设置中运行，否则它将无法获取用户和组信息。 在这种情况下，应该与外部操作系统联系以获取此信息。 要完成此任务，请直接调用与该域相关联的服务器中的注册表。 要使此操作成功，与该域相关联的服务器必须已启动。 还必须将顶级安全性定制属性中的属性 com.ibm.websphere.allowRegistryLookupOnProcess 设置为 true。 设置此属性之后，Deployment Manager 代码将搜索其中一个与该安全域相关联的服务器并直接从中获取用户和组信息。 您可以通过调用其中一个服务器中的 MBean 来完成此任务。

如果无法访问任何正在使用该域的服务器中的 MBean，那么管理控制台将显示一个面板，您可以在该面板中手动输入每个用户和组的用户和 accessId 信息。 在此字段中输入正确的 accessId 格式至关重要。 用户的 accessId 格式为 user:realmName/userUniqueId。 realmName 是用户所在的领域的名称，userUniqueId 是代表该用户的 uniqueId，这取决于所使用的注册表。

例如，对于 LDAP ， uniqueUserId 是专有名称 (DN) ，对于 Windows localOS 注册表，它是用户的 SID。 对于 Unix 平台，它是 UID。 对于定制注册表，它取决于实现。

同样，对于组而言，accessId 格式为 group:realmName/groupUniqueId。 如前所述，使用 listRegistry用户和 listRegistry组命令，并将-displayAccessIds 选项设置为 true ，以便您可以获取您感兴趣的域或域的正确格式。

将可信领域中的用户和组或者 AllAuthenticatedInTrustedRealms 特殊主体集添加到应用程序的授权表之后，它就能够接受来自其他正在使用其任何可信领域的应用程序的请求。 在接收服务器上执行的 LTPA 令牌验证将先进行检查，以确保该领域可信。 然后，授权引擎会进行检查，以了解外部用户和/或组或者特殊主体集 AllAuthenticatedInTrustedRealms 是否已被授予访问资源所需的角色访问权。 如果拥有访问权，那么将授予访问权。

仅当使用 WebSphere 内置授权时，跨领域通信才适用。 如果您正在使用其他授权引擎 (包括 SAF for z/OS) ，那么可以通过实现将外部用户映射到其自己的存储库中的用户的定制登录模块来实现任何跨领域授权。

将节点与安全域联合

如果在基本版本中配置安全域并使其与单元联合，那么在基本版本中配置的安全域还将针对该单元中的该服务器进行配置。 在联合之前和之后，该服务器都可以使用同一域安全性配置。 如果要将基本服务器与某个单元联合，那么对该安全域分配的资源应该限于服务器范围而非单元作用域。

如果该基本服务器要向管理代理程序进程注册，并且您打算让基本概要文件中的所有服务器都使用此安全域，请使用单元作用域作为资源。

在联合期间，如果基本服务器中的安全域在单元级别已存在，那么 addNode 命令将失败。 可以使用-excludesecuritydomains 选项在联合期间不包含安全域。

从单元中除去所联合的节点时，应该从安全域中除去该节点中的资源。 如果安全域有与其相关联并且跨节点的集群，那么不会除去那些节点。 通过使用脚本编制命令或管理控制台，您始终能够从安全域或者任何未被使用的域中除去资源。

混合版本环境中的安全域

一旦将所有节点都迁移到最新版本，您就应该创建安全域， 在需要使单元与某个域相关联时尤其应该如此。 但是，如果要在混合版本环境中创建安全域，请注意下列各项：

修改安全域

您可以使用管理控制台任务或脚本编制命令来修改安全域。 要获取管理任务和脚本编制命令的完整列表，请参阅本文档末尾的“相关任务”中的链接。

在创建安全域并使其与一组作用域相关联之后，必须重新启动与这个新域相关联的服务器。 在重新启动之后，与新域相关联的作用域中的应用程序将使用该域中定义的安全性属性。

对任何域属性所作的更改都要求重新启动所有对该域指定的作用域。 如果添加了新作用域，那么还需要重新启动这些作用域。 对域配置所作的任何修改（对安全性属性所作的修改或者对作用域所作的修改）都将影响那些正在使用该域配置的应用程序。

对现有的域进行修改之前，请考虑下列潜在的影响。 例如，除去某个域中配置的用户注册表并重新启动服务器之后，将使用单元范围的域中的用户注册表（如果已定义此用户注册表）或全局安全性配置。 这可能会对应用程序认证和授权产生影响。 与应用程序相关联的用户和组在新注册表中可能不再有效。 另一个要考虑的示例是，从域中除去 JAAS 配置。 依赖于此配置的应用程序将不再能够使用 JAAS 配置。 每当安全性配置更改时，都有可能会影响到应用程序，因此，所有安全性配置更改都应该在极为谨慎的情况下进行。

混合发行环境需要的容许 PTF

对于先前版本的 WebSphere Application Server for z/OS IIOP 客户机与托管多个安全域的 WebSphere Application Server V 9.0 for z/OS 应用程序服务器进行互操作的混合发行版环境，需要使用容许 PTF。

V 9.0 之前的 IIOP 客户机需要更新其 IIOP 定位处理代码以在 V 9.0 应用程序服务器的安全域中执行 IIOP 定位。

在本节的后文中列示了所有受影响的服务发行版的容许 PTF。 V 9.0 之前的 IIOP 客户机必须处于或高于给定服务级别，才能成功与包含多个安全域的 V 9.0 应用程序服务器进行互操作。

此需求仅适用于针对配置并启用了多个安全域的 WebSphere for z/OS 应用程序服务器调用请求的 WebSphere for z/OS IIOP 客户机。