多个安全域

WebSphere® 安全域 (WSD) 使您能够灵活地在 WebSphere Application Server 中使用不同的安全性配置。WSD 也称为多个安全域或简称为安全域。可以为不同的应用程序配置不同的安全性属性,例如 UserRegistry。

注: WebSphere Application Server V7.0 中引入了多安全域支持。可以创建不同的安全性配置并将它们分配给 WebSphere Application Server 进程中的不同应用程序。通过创建多个安全域,可以为单元环境中的管理应用程序和用户应用程序配置不同的安全性属性。可以将不同的应用程序配置为使用不同的安全性配置,方法是将主管这些应用程序的服务器、集群或服务集成总线分配给这些安全域。只有已被分配管理员角色的用户才能配置多个安全域。

安全域为何有用

WebSphere 安全域具有以下两个主要优点:

  • 可以给 WebSphere Application Server 管理应用程序配置一组有别于用户应用程序的安全性配置。
  • 它们使一组应用程序能够与另一组应用程序具有不同的安全性配置组。

    [z/OS]例如,可以将 WebSphere Application Server 管理功能配置为使用 RACF® 的用户注册表,而将应用程序配置为使用 LDAP 的用户注册表。

    [AIX Solaris HP-UX Linux Windows][IBM i]例如,可以将 WebSphere Application Server 管理功能配置为使用联合存储库的用户注册表,而将应用程序配置为使用 LDAP 的用户注册表。

在先前版本的 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 中的用户应用程序以及集群中的用户应用程序分别使用 Domain2Domain3 中定义的安全性属性(其原因在于,这些作用域与这些域相关联)。服务器 S2.2 未与任何域相关联。因此,在缺省情况下,S2.2 中的用户应用程序将使用与该单元相关联的域 (Domain1)。在域级别不存在的安全性属性将从全局配置中获取。

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

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

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

安全域的内容

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

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

图 3. 与主安全域相关的文件的位置和内容与主安全域相关的文件的位置以及那些文件的内容。
注: 您不应手动修改这些文件。而是应使用管理控制台任务或脚本编制命令来修改文件。要获取管理任务和脚本编制命令的完整列表,请参阅本文档末尾的“相关任务”中的链接。

创建安全域

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

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

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

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

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

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

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

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

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

为安全域配置属性

WebSphere Application Server V9.0 中,可以在域级别配置的安全性属性如下:

  • 应用程序安全性
  • Java™ 2 安全性
  • 用户领域(注册表)
  • 信任关联
  • 简单且受保护的 GSS-API 协商 (SPNEGO) Web 认证
  • RMI/IIOP 安全性 (CSIv2)
  • JAAS 登录(应用程序、系统和 J2C 认证数据)
  • Java 认证 SPI
  • 认证机制属性
  • 授权提供程序
  • 联合存储库
  • [z/OS]z/OS® 属性
  • 定制属性

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

无法在域级别覆盖的某些其他熟知属性是 Kerberos、审计、Web 单点登录 (SSO) 和 Tivoli® Access Manager (TAM)。安全套接字层 (SSL) 属性已支持不同的作用域,但它不是域配置的一部分。对于域级别上不受支持的所有属性,域中的用户应用程序会从全局级别共享其配置。

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

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

通过与 TAM 服务器联系,Tivoli Access Manager 客户机运行时用于提供认证(由 TrustAssociationInterceptor 和 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 V9.0 中,可以在单元级别、服务器级别、集群级别和服务集成总线级别关联安全域。
注: 有关 WebSphere Application Server V9.0 的多个安全域中服务集成总线和总线安全性的更多信息,请参阅消息传递安全性和多个安全域

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

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

还可以使安全域与单元相关联。进行此关联通常是因为您要使 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,请从服务器级别除去安全性配置,然后创建具有同一组安全性属性的安全域。

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

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

  1. 应用程序安全性:

    选择“启用应用程序安全性”,以对用户应用程序启用或禁用安全性。如果禁用了此选项,那么安全域中的所有 EJB 和 Web 应用程序都将不再受保护。授予对这些资源的访问权而不进行用户认证。如果启用了此选项,那么将对安全域中的所有 EJB 和 Web 应用程序强制启用 J2EE 安全性。仅当在全局安全性配置中启用了全局安全性时才能强制启用 J2EE 安全性。即,如果不首先在全局级别启用全局安全性,那么不能启用应用程序安全性。

  2. Java 2 安全性:

    选择“使用 Java 2 安全性”,以实现在域级别启用或禁用 Java 2 安全性或者指定或添加与 Java 2 安全性相关的属性。此选项将在进程 (JVM) 级别启用或禁用 Java 2 安全性,以便所有应用程序(管理应用程序和用户应用程序)都可以启用或禁用 Java 2 安全性。

  3. 用户域(用户注册表):

    此部分使您能够为安全域配置用户注册表。可以单独配置在域级别使用的任何注册表。有关更多信息,请参阅为安全域配置属性

    在域级别配置注册表时,可以选择为注册表定义您自己的域名。通过域名可将一个用户注册表域与另一个用户注册表区分开。领域名可用于多个位置:在 Java 客户机登录面板中用来提示用户,用于认证高速缓存中,还可以在使用本机授权时使用领域名。

    在全局配置级别上,系统会为用户注册表创建域。在先前发行版的 WebSphere Application Server 中,系统中只配置了一个用户注册表。当您具有多个安全域时,可以在系统中配置多个注册表。对于在这些域中是唯一的那些域,可为安全域配置您自己的域名。如果确定此域名唯一的,那么还可以选择系统以创建唯一的域名。在后一种情况下,域名基于所使用的注册表。

    对于 LDAP 注册表,LDAP 服务器的 host:port 是系统生成的域名。对于 localOS,localOS 机器的名称为域名。对于定制用户注册表,该域是定制注册表实现的 getRealm ( ) 方法返回的那个域。

    如果系统生成的域名足够唯一,那么可选择选项以让系统生成域名。否则,请为您已配置用户注册表的每个安全域选择唯一的域名。如果底层的用户资源库相同,请在不同域中使用同一域名。从安全性运行时角度来看,相同领域名具有同一组用户和组信息。例如,当域中需要用户和组信息时,会使用与该域相匹配的第一个用户资源库。

    如果为任何域配置了非集中式 localOS 注册表,并且该域与非 Deployment Manager 所在的系统上节点中的服务器或集群相关联,那么必须提供域名。此域名必须与节点上生成的域名相同。此域名可通过在该节点上对 SecurityAdmin MBean 调用 getRealm() 方法来获取。通常,用于 localOS 注册表的域名为机器的主机名。在此情况下,不应该让系统生成域名,而应该获取节点中进程使用的域名。

    如果在配置用户注册表时,您选择系统来为 localOS 注册表生成域,那么系统会选择 Deployment Manager 使用的 localOS 注册表。如果已配置的域与服务器使用的域不相匹配,那么会存在授权问题。此外,请注意,在此情况下,使用此本地注册表的域只能与属于同一机器上节点的服务器和集群相关联。

    WebSphere Application Server V7.0 中,只能在全局级别配置联合存储库用户注册表,并且每个单元只有一个实例,但任何域都可通过将此注册表配置为活动注册表来使用此注册表。在 WebSphere Application Server V8.0 中,可在多安全域环境中的域级别配置联合存储库的唯一实例。

    从全局级别复制安全域时,还会将在全局级别定义的用户和组复制到该安全域。从现有域中进行复制时也是如此。新创建的安全域将使用基于文件的 VMM 存储库,此安全域要求用户为该存储库填充用户和组。

    在此 WebSphere Application Server 的发行版中也新增了内容,“领域配置设置”管理控制台页面上新增了一个复选框(即“对模型使用全局模式”)用于为多安全域环境中的数据模型设置全局模式选项。全局模式是指管理域的模式。

    当多个用户注册表处于进程中时,使用“UserRegistry”作为查询名称的命名查询会返回用户应用程序使用的用户注册表。将通过查询名称“AdminUserRegistry”来绑定管理应用程序使用的用户注册表。

    跨领域通信中所述,当一个域中的应用程序与另一个域中的应用程序通过使用 LTPA 令牌进行通信时,必须信任这些域。您可以使用“用户注册表”面板中的可信认证领域 –入站链接或者使用 addTrustedRealms 命令来建立信任关系。可在不同域之间建立信任关系。登录到一个域中的用户可以访问另一个域中的资源。如果在这两个域之间未建立信任关系,那么 LTPA 令牌验证会失败。

    注: web.xml 文件中使用的域名与用户注册表域不相关。
  4. 信任关联:

    如果在域级别配置信任关联拦截器 (TAI),那么会为了便利起见,而将在全局级别配置的拦截器复制到该域级别。可以在域级别修改拦截器列表,以适合您的需求。请仅配置那些要在该域级别使用的拦截器。

    只能在全局级别配置 Tivoli Access Manager 的信任关联拦截器。域配置也可以使用它们,但是不能具有不同版本的信任关联拦截器。在单元中只能存在 Tivoli Access Manager 的信任关联拦截器的一个实例。

  5. SPNEGO Web 认证:

    可以在域级别配置 SPNEGO Web 认证,此认证使您能够配置 SPNEGO 以进行 Web 资源认证。

    注:WebSphere Application Server V6.1 中引入了一种 TAI,该 TAI 使用“简单且受保护的 GSS-API 协商机制 (SPNEGO)”来安全地协商和认证对受保护资源发出的 HTTP 请求。建议不要在 WebSphere Application Server 7.0 中使用此功能。SPNEGO Web 认证已取代该 TAI,以提供动态重新装入 SPNEGO 过滤器的功能以及对应用程序登录方法启用回退。
  6. RMI/IIOP 安全性 (CSIv2):

    RMI/IIOP 安全性属性是指 CSIv2(公共安全互操作性 V2)协议特性。当您在域级别配置这些属性时,为了方便起见,将复制全局级别的 RMI/IIOP 安全性配置。

    可以更改那些需要在域级别互不相同的属性。对于全局级别和域级别,用于 CSIv2 入站通信的传输层设置应相同。如果它们不相同,那么会将域级别的属性应用到进程中的所有应用程序。

    当一个进程与具有不同域的另一个进程通信时,除非下游服务器列示在出站可信域列表中,否则不会将 LTPA 认证和传播令牌传播至该服务器。这可以通过使用 CSIv2 – 出站通信面板上的可信认证领域出站链接或通过使用 addTrustedRealms 命令任务来执行。请参阅跨领域通信以了解更多信息。

  7. JAAS(Java 认证和授权服务):

    JAAS 应用程序登录、JAAS 系统登录和 JAAS J2C 认证数据别名都可以在域级别进行配置。缺省情况下,系统中的所有应用程序都可以访问在全局级别配置的 JAAS 登录。安全性运行时首先会在域级别查找 JAAS 登录。如果找不到这些登录,那么会接着在全局安全性配置中进行查找。仅当需要指定供安全域中的应用程序独占使用的登录时,才在域中配置任何这些 JAAS 登录。

    仅对于 JAAS 和定制属性,只要为域定制了全局属性,用户应用程序仍然可以使用这些全局属性。

  8. Java 认证 SPI (JASPI)

    指定 Java 认证 SPI (JASPI) 认证提供程序和相关联的认证模块的配置设置,以在域级别进行应用。

    选择提供程序,以创建或编辑 JASPI 认证提供程序。

    注: 可以通过在域级别配置的提供程序启用 JASPI 认证提供程序。缺省情况下,系统中的所有应用程序都可以访问在全局级别配置的 JASPI 认证提供程序。安全性运行时将首先在域级别检查 JASPI 认证提供程序。如果找不到这些登录,那么会接着在全局安全性配置中进行查找。仅当该安全域中的应用程序要独占地使用 JASPI 认证提供程序时,才应该在域中配置该提供程序。
  9. 认证机制属性:

    指定必须在域级别应用的各种高速缓存设置。

    1. 认证高速缓存设置 - 用来指定认证高速缓存设置。在此面板上指定的配置仅适用于此域。
    2. LTPA 超时 - 可以在域级别配置不同的 LTPA 超时值。缺省超时值是 120 分钟,此值是在全局级别设置的。如果在域级别设置了 LTPA 超时,那么将使用此到期时间来创建在访问用户应用程序时在安全域中创建的任何令牌。
    3. 使用域限定的用户名 - 当启用了此选项时,将使用安全域 (security domain) 中的应用程序所使用的安全域(security realm,用户注册表)来限定由诸如 getUserPrincipal( ) 等方法返回的用户名。
  10. 授权提供程序:

    可以在域级别配置外部的第三方 JACC (Java Authorization Contract for Containers) 提供程序。只能在全局级别配置 Tivoli Access Manager 的 JACC 提供程序。安全域仍可以使用此 JACC 提供程序(如果它们未使用另一个 JACC 提供程序来覆盖此授权提供程序)。

    JACC 属性(例如策略对象)基于 JVM 级别。这意味着,在 JVM 进程中只能有一个 JACC 策略对象。但是,如果配置了多个 JACC 提供程序,那么 Deployment Manager 进程必须在同一个 JVM 中处理所有这些提供程序,这是因为,它必须根据应用程序名称将应用程序的授权策略传播到相应的提供程序。

    如果 JACC 提供程序能够处理将授权策略传播到多个提供程序这一工作,那么您可以在全局级别对其进行配置。在这种情况下,在安装应用程序时,将在 Deployment Manager 进程中调用此 JACC 提供程序,并且,此 JACC 提供程序负责根据 contextID 中传递的应用程序名称将信息传播到相应的 JACC 提供程序。

    另一种实现此目标的方法是,在全局安全性级别设置定制属性 com.ibm.websphere.security.allowMultipleJaccProviders=true。如果设置了此属性,那么 WebSphere Application Server 会将授权策略信息传播到 JACC 提供程序,该提供程序与对应于将安装该应用程序的目标服务器的域相关联。因为受管服务器未主管多个 JACC 提供程序,所以此属性只用于 Deployment Manager 进程。

    [z/OS]另外,还可以在安全域级别配置 SAF 授权选项,这些选项包括:
    • 未经认证的用户标识
    • SAF 概要文件映射器
    • 是否启用 SAF 委托
    • 是否使用 APPL 概要文件来限制对 WebSphere Application Server 的访问
    • 是否消除授权失败消息
    • SMF 审计记录策略
    • SAF 概要文件前缀

    [z/OS]CBIND 检查被认为是管理操作,因此,在确定要检查的 CBIND 资源的名称时,将使用所指定的 SAF 概要文件前缀的全局值。例如:CB.BIND.<cluster_name SAF_profile_prefix>。

    [z/OS]有关 SAF 授权选项的更多信息,请参阅z/OS 系统授权工具授权

  11. 定制属性:

    请在域级别设置新的定制属性或者设置与全局级别的定制属性不同的定制属性。缺省情况下,单元中的所有应用程序都可以访问全局安全性配置中的所有定制属性。安全性运行时代码首先在域级别查找定制属性。如果未找到定制属性,那么它会尝试从全局安全性配置中获得定制属性。

    仅对于 JAAS 和定制属性,只要为域定制了全局属性,用户应用程序仍然可以使用这些全局属性。

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

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

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

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

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

通常,当 Java 客户机需要向多个不同的领域进行认证时,它必须为所有那些领域提供凭证信息。如果登录源是 promptstdin,那么它将被提示登录多次,即,针对每个领域进行一次登录。如果登录源设置为 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 属性时,会将第一次登录的同一主体集用于后续登录。如果需要更改主体集信息,那么不应设置此属性。

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

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

如果您不知道域名,请使用 <default> 作为域名。在这种情况下,将向应用程序领域执行认证。如果未对命名读操作分配 Everyone 特殊主体集,那么您必须提供管理应用程序所使用的领域(全局安全性配置中使用的注册表)以及该注册表中的相应用户和密码信息才能确保查找操作成功。

在查找操作成功后,请通过提供应用程序领域(或 <default>)以及该应用程序所使用的注册表中相应用户的用户和密码信息来执行另一次程序化登录。这类似于登录源为 prompt 的情况。您必须执行两次认证,第一次针对全局安全性配置所使用的注册表进行认证(为了执行命名查找操作),第二次针对应用程序所使用的注册表进行认证(为了访问 EJB)。

如果在 $WAS_HOME/profiles/$ProfileName/properties/sas.client.props 文件中将 com.ibm.CORBA.validateBasicAuth 设置为 false,那么程序化登录可以使用 <default> 作为用于查找操作和 EJB 操作的域名。仅当在服务器端访问资源时,才会进行实际的认证,在这种情况下,将根据所访问的资源来计算领域。

WebSphere Application Server V7.0 开始提供的新安全域支持未更改当前应用程序安全性编程模型。但是,它更为灵活并提供了更多功能,例如:

  • 用户应用程序仍可以通过对“UserRegistry”执行命名查找来找到用户注册表对象。对于管理应用程序所使用的注册表对象,可以对“AdminUserRegistry”执行命名查找。
  • 在多域设置中,未更改应用程序对 JAAS 登录配置的用法。但是,如果应用程序必须引用在域级别指定的 JAAS 配置,那么该应用程序的管理员和部署员必须确保对此域配置该应用程序所需的 JAAS 配置。
  • 如果应用程序需要使用不同的领域与其他应用程序进行通信,那么使用 LTPA 令牌时,应该为入站通信和出站通信都建立信任关系。请参阅跨领域通信以了解更多信息。
  • 在应用程序中使用程序化登录时,如果要登录到该应用程序所使用的领域,请使用 <default> 作为域名,或者提供该应用程序正在使用的域名。如果需要登录到全局领域,那么必须提供全局域名。如果您提供任何其他领域,那么将只创建基本认证主体集。当请求实际地流向主管该领域的服务器时,如果该服务器主管该领域,那么将发生实际的用户认证。如果该服务器未主管该领域,那么登录将失败。

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

在多域设置中部署应用程序时,应该将该应用程序中的所有模块都安装在属于同一个安全域的服务器或集群中。否则,根据这些安全域中配置的安全性属性不同,可能会出现不一致的行为。例如,如果这些域包含不同的用户注册表,那么用户和组信息可能不同,这可能导致访问模块时出现不一致的行为。另一个示例是,安全域之间的 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 令牌的领域。这称为入站可信领域。

您可以通过使用 –communicationType 选项设置为 outbound 的 addTrustedRealms 命令来建立出站可信领域。另外,也可以通过在管理控制台中的 CSIv2 出站通信面板上单击可信认证领域 - 出站来建立此领域。

您可以通过使用 –communicationType 选项设置为 inbound 的同一个 addTrustedRealms 命令任务来建立入站可信领域。另外,也可以使用管理控制台来建立此领域。

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

  • 在 Domain1 中,realm1 应该信任 realm2 以进行出站通信。
  • 在 Domain2 中,realm2 应该信任 realm1 以进行入站通信。
  • 应该在 app2 的授权表中配置 user1 的 accessId。

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

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

  • 在单元之间共享 LTPA 密钥。
  • 通过使用 wsadmin 实用程序来更新 app2 的授权表,在其中指定外来用户和组的 accessId。管理控制台无权访问单元作用域外部的领域。
图 4. 多域环境中的跨领域通信如果以上示例中的应用程序部署在不同的单元中,那么您必须执行下列操作:在单元之间共享 LTPA 密钥,并通过使用 wsadmin 实用程序来更新 app2 的授权表,以便在其中指定外来用户和组的 accessId。管理控制台无权访问单元作用域外部的领域。

在领域之间建立信任关系后,当服务器接收到 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。如上所述,请使用 –displayAccessIds 选项设置为 true 的 listRegistryUsers 和 listRegistryGroups 命令,以便获取对您所感兴趣的域或领域而言正确的格式。

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

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

将节点与安全域联合

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

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

在联合期间,如果基本服务器中的安全域在单元级别已存在,那么 addNode 命令将失败。您可以使用 –excludesecuritydomains 选项来指定在联合期间不包括该安全域。

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

混合版本环境中的安全域

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

  • 如果在混合版本设置中创建单元范围的域,那么将自动创建名为 PassThroughToGlobalSecurity 的域。创建单元范围的域时,会将所有混合集群分配到这个域。这个 PassThroughToGlobalSecurity 域比较特殊,即,无法向其添加属性,而只能对其分配资源。

    分配给 PassThroughToGlobalSecurity 域的所有资源都使用全局安全性配置信息。每当将混合版本设置中的节点迁移到最新版本时,都会将这些节点中的服务器和集群添加到这个域。这些节点中的所有服务器和集群中的应用程序都不使用单元范围的域;而是,它们在迁移前后都使用全局安全性配置。

    如果任何这些服务器需要使用单元范围域,那么必须从此 PassThroughToGlobalSecurity 域中除去这些资源。在已迁移节点中创建的新服务器和集群使用单元范围域,而不是 PassThroughToGlobalSecurity 域。因此,存在混合的服务器和集群,其中的一些服务器和集群使用全局安全性配置,而另一些则使用单元范围的域。

  • 创建单元范围的域之后,将任何旧版本集群成员添加到 WebSphere Application Server V9.0 集群将受限制,这是因为,此操作将使其成为混合集群。如果 WebSphere Application Server V9.0 集群与某个域相关联,那么将先前版本的集群成员添加到此集群时也存在此限制。此限制旨在避免使安全域与混合集群相关联。
  • 如果有可能,您应该在所有节点迁移完毕后才创建单元范围的域。在这种情况下,单元范围的域将适用于整个单元,而不仅仅适用于该单元的某些部分。这还使您不必创建 PassThroughToGlobalSecurity 域以及具有安全域的混合集群方案。

修改安全域

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

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

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

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

[z/OS]

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

对于混合发行环境,容许 PTF 是必需的,在这些环境中,先前版本的 WebSphere Application Server for z/OS IIOP 客户机与托管多个安全域的 WebSphere Application Server for z/OS V9.0 应用程序服务器进行互操作。

V9.0 之前的 IIOP 客户机需要对其定位处理代码进行更新,以在 V9.0 应用程序服务器的安全域之间执行 IIOP 定位。

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

WebSphere Application Server for z/OS 5.1:W510246
WebSphere Application Server for z/OS V6.0:602.29
WebSphere Application Server for z/OS V6.1:610.17

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


指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_sec_multiple_domains
文件名:csec_sec_multiple_domains.html