Menu Close
Settings Close

Language and Page Formatting Options

安全架构

Red Hat JBoss Enterprise Application Platform 7.4

高级红帽 JBoss 企业应用平台安全概念和功能说明,以及支持它们的组件.

摘要

本文档重点介绍了 JBoss EAP 中安全性的高级概念,以及实施这些概念有哪些组件。本文档重点介绍了如何配置特定场景的具体内容以及原因及较少内容,其他文档中将着重介绍如何配置特定场景。完成本文档时,读者应当对 JBoss EAP 内安全性组件具有扎实的概念性理解,以及这些组件如何配合使用。

对红帽文档提供反馈

我们感谢您对我们文档的反馈。要提供反馈,您可以突出显示文档中的文本并添加注释。按照以下步骤了解提交对红帽文档的反馈。

先决条件

  • 登录红帽客户门户。
  • 在红帽客户门户中,以多页 HTML 格式查看文档。

流程

  1. 单击 Feedback 以查看现有读取器注释

    注意

    反馈功能仅以多页 HTML 格式启用。

  2. 突出显示您要提供反馈的文档中的部分。
  3. 在显示在您选择的文本附近的提示菜单中,单击 Add Feedback

    文本框将在页面右侧的"反馈"部分中打开。

  4. 在文本框中输入您的反馈,然后单击 Submit

    您已创建了文档问题。

  5. 要查看问题,请单击反馈视图中的问题跟踪器链接。

使开源包含更多

红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。详情请查看 CTO Chris Wright 信息

第 1 章 常规安全概念概述

在了解 JBoss EAP 如何处理安全性之前,务必要了解几个基本的安全概念。

1.1. 身份验证

身份验证指的是识别对象并验证身份的真实性。最常见的身份验证机制是用户名和密码组合,但也使用共享密钥、智能卡或指纹等其他机制进行身份验证。在 Jakarta EE 声明性安全性的情况下,成功身份验证的结果称为主体。

1.2. 授权

授权指的是指定访问权限或定义访问策略的一种方法。然后,系统可以实施一种机制,利用这些策略来允许或拒绝为请求者访问资源。在很多情况下,这通过将主体与一组允许访问的操作或位置匹配来实现,有时也称为角色。

1.3. 练习中的身份验证和授权

尽管身份验证和授权是不同的概念,但通常将它们链接在一起。许多为处理身份验证而编写的模块也可以处理授权,反之亦然。

示例

应用 MyPersonalSoapbox 提供了发布和查看消息的功能。拥有 Talk 角色的主体 可以发布消息并查看其他已发布的信息。没有登录的用户具有 Listen 角色,并且可以查看已发布的消息。Suzy、Adam 和 Bob 使用 应用程序。Suzy 和 Bob 可以使用其用户名和密码进行身份验证,但 Adam 尚不具有用户名和密码。Suzy 具有 Talk 角色,但 Bob 没有任何角色,包括 Talk 和 Listen。当 Suzy 验证后,她可以发布并查看消息。当 Adam 使用 MyPersonalSoapbox 时,他无法登录,但可以看到已发布的消息。当 Bob 登录时,他无法发布任何消息,也不能查看任何其他已发布的消息。

Suzy 同时经过身份验证和授权。Adam 尚未通过身份验证,但获得授权,能够使用 Listen 角色查看消息。Bob 经过身份验证,但没有授权,也没有角色。

1.4. Encryption

加密指的是通过应用数学算法来编码敏感信息。通过将数据转换为编码的格式来保护数据。要再次读取数据,必须将编码的格式转换为原始格式,或将其解密。加密可应用于文件或数据库中的简单字符串数据,甚至适用于跨通信流发送的数据。

加密示例包括如下情况:

  • LUKS 可用于加密 Linux 文件系统磁盘。
  • blowfish 或 AES 算法可用于加密存储在 Postgres 数据库中的数据。
  • HTTPS 协议通过安全套接字层/传输层安全(SSL/TLS)加密所有数据,然后将其从一个方传输到另一个方。
  • 当用户使用 Secure Shell(SSH 协议)从一个服务器连接到另一服务器时,所有通信都将通过加密隧道发送。

1.5. SSL/TLS 和证书

SSL/TLS 使用在 和 仅由这两个系统识别的对称密钥来加密两个系统之间的网络流量。为确保对称密钥进行安全交换,SSL/TLS 使用公钥基础架构(PKI),这是一种使用密钥对的加密方法。密钥对由两个独立但匹配的加密密钥组成:一个公钥和一个私钥。公钥与各方共享,用于加密数据;私钥是保密的,用于解密已使用该公钥加密的数据。

当客户端请求安全连接交换对称密钥时,在可以开始安全通信之前,会发生握手阶段。在 SSL/TLS 握手期间,服务器以证书的形式将其公钥传递给客户端。证书包含服务器的身份、其 URL、服务器的公钥,以及验证证书的数字签名。客户端验证证书,并决定是否信任证书。如果证书受信任,客户端将为 SSL/TLS 连接生成对称密钥,使用服务器的公钥对其进行加密,并将它发回到服务器。服务器使用其私钥解密对称密钥。通过此连接在两台计算机之间进行进一步通信使用对称密钥进行加密。

证书有两种:自签名证书和授权签名证书。自签名证书使用其私钥自行签名;签名未通过验证,因为它没有连接到信任链。颁发机构签名证书是指由证书颁发机构、CA 签发的证书,由该 CA 签名,如 VeriSign、CAcert 或 RSA。CA 验证证书持有者的真实性。

自签名证书可以更快、更容易生成,并且管理的基础架构更少,但客户可能难以验证其真实性,因为第三方尚未确认其真实性。这本质上可以降低自签名证书的安全性。授权签名的证书可以更加努力设置,但便于客户端验证其真实性。创建了信任链,因为第三方已确认证书持有者的真实性。

警告

红帽建议显式禁用 SSLv2、SSLv3 和 TLSv1.0,以便在所有受影响的软件包中明确禁用 TLSv1.1 或 TLSv1.2。

1.6. 单点登录

单点登录(SSO)允许一个资源验证主体隐式授权对其他资源的访问权限。如果 SSO 对一组不同资源进行保护,则用户只需要在第一次访问任何受保护的资源时进行身份验证。身份验证成功后,与用户关联的角色将存储并用于授权所有其他相关资源。这允许用户访问任何其他授权资源,而无需重新进行身份验证。

如果用户注销资源或资源以编程方式使会话无效,则移除所有持久的授权数据并重新开始进程。在资源会话超时的情况下,如果存在与该用户关联的其他有效资源会话,SSO 会话不会失效。SSO 可用于 Web 应用和桌面应用的身份验证和授权。在某些情况下,SSO 实施可以与这两者集成。

SSO 中有几个常用的术语,用于描述系统的不同概念和部分。

Identity Management

身份管理(IDM)是指在一个或多个系统或域中管理主体及其关联的身份验证、授权和特权的理念。术语身份和访问管理(IAM)有时用于描述同一概念。

身份供应商

身份提供商(IDP)是负责验证最终用户并以可信方式向受信任的合作伙伴断言该用户的身份的权威实体。

Identity Store

身份提供商需要身份存储来检索用户在身份验证和授权过程中要使用的信息。身份存储可以是任何类型的存储库:数据库、轻量级目录访问协议(LDAP)、属性文件等。

服务提供商

服务提供商(SP)依靠身份提供程序通过电子用户凭证来断言用户的信息,让服务提供商根据一组受信任的用户凭据断言来管理访问控制和控制。

集群和非集群的 SSO

非集群 SSO 限制在同一虚拟主机上为应用共享授权信息。在主机发生故障时,也没有弹性。在集群的 SSO 场景中,可以在多个虚拟主机上的应用之间共享数据,使它具有应对故障的弹性。此外,集群 SSO 能够接收来自负载平衡器的请求。

1.6.1. 第三方 SSO 实施

Kerberos

Kerberos 是客户端-服务器应用的网络身份验证协议。它使用密钥对称加密,以允许在非安全网络中进行安全身份验证。

Kerberos 使用名为 ticket 的安全令牌。要使用安全服务,用户需要从问题单授予服务(TGS)获取票据,这是在其网络的服务器上运行的服务。在获取票据后,用户从身份验证服务(AS)请求一个 Service Ticket(ST),这是在同一网络中运行的另一个服务。然后,用户使用 ST 向所需的服务进行身份验证。TGS 和 AS 在名为密钥分发中心(KDC)的封闭服务中运行。

Kerberos 设计为在客户端-服务器桌面环境中使用,通常不用于 Web 应用程序或瘦客户端环境。但是,许多组织使用 Kerberos 系统进行桌面身份验证,更喜欢重新使用现有系统,而不是为其 Web 应用程序创建第二个系统。Kerberos 是 Microsoft Active Directory 的完整组成部分,用于许多红帽企业 Linux 环境中。

SPNEGO

简单且受保护的 GSS_API 协商机制(SPNEGO)提供了一种机制,可用于扩展基于 Kerberos 的 SSO 环境,供 Web 应用使用。

当客户端计算机上的应用(如 Web 浏览器)尝试访问 Web 服务器上的受保护页面时,服务器需要响应该授权。然后,应用程序从 KDC 请求 ST。应用程序以格式化为 SPNEGO 的请求打包票据,并通过浏览器将其发回到 Web 应用程序。运行部署的 Web 应用的 Web 容器解压缩请求并验证票据。访问权限是在成功通过身份验证后授予的。

SPNEGO 与所有类型的 Kerberos 提供商合作,包括红帽企业 Linux 中的 Kerberos 服务和 Kerberos 服务器(这是 Microsoft Active Directory 的完整组成部分)。

Microsoft 的 Active Directory

Active Directory(AD)是由 Microsoft 开发的目录服务,用于验证 Microsoft Windows 域中的用户和计算机。它作为 Windows Server 的一部分提供。运行 Windows Server 控制域的计算机称为域控制器。红帽企业 Linux 可与 Active Directory 域集成,支持红帽身份管理、红帽 JBoss 企业应用平台和其他红帽产品。

Active Directory 依赖于三个可协同工作的核心技术:

  1. LDAP 以存储有关用户、计算机、密码和其他资源的信息
  2. Kerberos,通过网络提供安全身份验证
  3. 域名服务(DNS),用于提供网络计算机和其他设备的 IP 地址和主机名之间的映射

1.6.2. 基于声明的身份

实施 SSO 的一种方法是使用基于声明的身份系统。基于声明的身份系统允许系统传递身份信息,但是将该信息提取为两个组件:一个声明以及签发者或授权。声明是指一个主题(如用户、组、应用程序或组织)对另一个主题所做的声明。该声明或声明集合打包到令牌或一组令牌中,并由提供程序发布。基于声明的身份允许单个安全资源实施 SSO,而不必了解关于用户的一切内容。

安全令牌服务

安全令牌服务(STS)是一种身份验证服务,向客户端发布安全令牌,以便在验证和授权安全应用、Web 服务或 Jakarta 企业 Bean 的用户时使用。试图对使用 STS(称为服务提供商)保护的应用进行身份验证的客户端将被重定向到集中式 STS 验证器并发布令牌。如果成功,该客户端将重新尝试访问服务提供商,并提供其令牌和原始请求。该服务提供商将通过 STS 验证客户端的令牌,并相应地进行操作。客户端可以针对其他 Web 服务或连接到 STS 的 Jakarta Enterprise Beans 重复使用此令牌。集中式 STS 的概念称为 WS-Trust,它可发布、取消、续订和验证安全令牌,并且指定安全令牌请求和响应消息的格式。

基于浏览器的 SSO

在基于浏览器的 SSO 中,一个或多个 Web 应用(称为服务提供商)在 hub 和 spoke 架构中连接到集中式身份提供程序。IDP 通过向服务提供商或 spoke 在 SAML 令牌中发布声明声明,充当身份和角色信息的中央来源或 hub。用户尝试访问服务提供商或用户尝试直接与身份提供程序进行身份验证时,可能会发出请求。它们分别称为 SP 启动和 IDP 启动的流,并且都将发布相同的申索声明。

SAML

安全断言标记语言(SAML)是一种数据格式,允许双方(通常是身份提供商和服务提供商)交换身份验证和授权信息。SAML 令牌是由 STS 或 IDP 发布的令牌类型;可用于启用 SSO。SAML、SAML 服务提供商保护的资源将用户重定向到 SAML 身份提供程序(一种 STS 或 IDP 类型),以在验证和授权该用户之前获取有效的 SAML 令牌。

基于桌面的 SSO

基于桌面的 SSO 使服务提供商和桌面域(如 Active Directory 或 Kerberos)能够共享一个主体。在实践中,这允许用户使用其域凭据登录其计算机,然后让服务提供商在身份验证期间重用该主体,而无需重新进行身份验证,从而提供 SSO。

1.7. LDAP

轻量级目录访问协议(LDAP)是在网络上存储和分发目录信息的协议。此目录信息包括有关用户、硬件设备、访问角色和限制的信息以及其他信息。

在 LDAP 中,区分名称(DN),唯一地标识目录中的对象。每个可分辨名称必须具有来自所有其他对象的唯一名称和位置,这可通过多个属性值对(AVP)来实现。AVP 定义通用名称和机构单元等信息。这些值的组合会产生 LDAP 所需的唯一字符串。

LDAP 的一些常见实施包括红帽目录服务器、OpenLDAP、Active Directory、IBM Tivoli 目录服务器、Oracle Internet 目录服务器和 389 目录服务器。

第 2 章 红帽 JBoss 企业应用平台如何从 Box 处理安全性

JBoss EAP 随附三个与安全性相关的组件:

这些组件基于常规安全概念概述中讨论的一般安全概念,但也在其实施中纳入了一些 JBoss EAP 特定的概念。

2.1. 核心服务、子系统和配置文件

JBoss EAP 基于模块化类加载的概念而构建。JBoss EAP 提供的每个 API 或服务都作为模块实施,该模块按需加载和卸载。核心服务是始终在服务器启动时加载并且需要在启动附加子系统之前运行的服务。

子系统是通过扩展添加到核心服务器的一组功能。例如,不同的子系统处理 servlet 处理,管理 Jakarta Enterprise Beans 容器,并提供 Jakarta Transactions 支持。

配置文件是子系统的命名列表,以及各个子系统配置的详细信息。具有大量子系统的配置文件将产生具有大量功能的服务器。具有一组小、重点的子系统的配置集将获得较少的功能,但占用空间比较小。默认情况下,JBoss EAP 附带若干预定义配置文件,例如 默认值full 、ha、full-ha。在这些配置文件中,管理接口和相关的安全域作为核心服务加载。

2.2. 管理接口

JBoss EAP 提供两个主要管理界面,用于与配置交互和编辑其配置:管理控制台和管理 CLI。这两个接口均提供 JBoss EAP 核心管理的功能。这些接口提供了两种方式来访问同一核心管理系统。

管理控制台是用于 JBoss EAP 的基于 Web 的管理工具。它可用于启动和停止服务器、部署和取消部署应用、调优系统设置,以及对服务器配置进行永久性修改。管理控制台还能够执行管理任务,并在任何更改要求重新启动或重新加载服务器实例时提供实时通知。在受管域中,可以从域控制器的管理控制台集中管理同一域中的服务器实例和服务器组。

管理 CLI 是 JBoss EAP 的命令行工具。管理 CLI 可用于启动和停止服务器、部署和取消部署应用、配置系统设置,以及执行其他管理任务。操作可以在批处理模式下执行,允许以组形式运行多个任务。管理 CLI 也可以连接受管域中的域控制器,从而在域中执行管理操作。管理 CLI 可以执行基于 Web 的管理工具可以执行的所有任务,以及基于 Web 的管理工具无法执行的其他较低级别操作。

注意

除了 JBoss EAP 附带的客户端外,还可以编写其他客户端,以使用 JBoss EAP 附带的 API 通过 HTTP 或原生接口调用管理接口。

2.3. Jakarta Management

Jakarta 管理提供了一种方式,可远程触发 JDK 和应用管理操作。JBoss EAP 的管理 API 公开为 Jakarta 管理 Bean。这些受管 Bean 被称为核心 MBean,其访问被控制和过滤与底层管理 API 本身完全相同。

除了管理 CLI 和管理控制台外,Jakarta 管理公开的 Bean 是访问和执行管理操作的替代机制。

2.4. 基于角色的访问控制

基于角色的访问控制(RBAC)是一种为管理用户指定一组权限的机制。它允许多个用户共享管理 JBoss EAP 服务器的职责,而无需每个用户都需要不受限制的访问权限。通过为管理用户提供职责分离,JBoss EAP 使组织能够轻松在个人或组之间分配责任,而无需授予不必要的特权。这可确保您的服务器和数据的最大安全性,同时仍然为配置、部署和管理提供灵活性。

JBoss EAP 中的 RBAC 通过角色权限和限制的组合来工作。提供了七个预定义角色,每个角色都有不同的固定权限。为每个管理用户分配一个或多个角色,指定用户在管理服务器时被允许执行的操作。

JBoss EAP 默认禁用 RBAC。

标准角色

JBoss EAP 提供了七个预定义用户角色: 监控器Operator维护者、Deploymenter 、Audi tor、管理员SuperUser。每个角色具有不同的权限集,专为特定用例而设计。MonitorOperatorMaintainerAdmin istra tor 和 SuperUser 角色连续相互构建,每个角色的权限都比以前多。AuditorDeployer 角色分别类似于 monitorMaintainer 角色,但它们具有一些特殊的权限和限制。

Monitor
Monitor 角色的用户 拥有最少的权限,只能读取服务器的当前配置和状态。此角色适用于需要跟踪和报告服务器性能的用户。监控器 无法修改服务器配置,也不能访问敏感数据或操作。
Operator
Operator 角色通过添加修改服务器的运行时状态的功能来扩展 monitor 角色。这意味着 Operator 可以重新加载和关闭服务器,以及暂停和恢复 Jakarta Messaging 目的地。Operator 角色是负责应用服务器的物理或虚拟主机的用户的理想选择,他们可以确保在需要时正确关闭和重新启动服务器。Operator 无法修改服务器配置或访问敏感数据或操作。
Maintainer
Maintainer 角色有权查看和修改运行时状态和除敏感数据和操作以外的所有配置。Maintainer 角色是无法访问敏感数据和操作的一般用途角色。Maintainer 角色允许用户获得几乎完全的访问权限来管理服务器,而无需授予这些用户对密码和其他敏感信息的访问权限。维护人员 无法访问敏感数据或操作。
Administrator
除了审计日志记录系统外,Administrator 角色对服务器上的所有资源和操作具有不受限制的访问权限。Administrator 角色可以访问敏感数据和操作。此角色还可以配置访问控制系统。只有在处理敏感数据或配置用户和角色时,才需要 Administrator 角色。管理员 无法访问审计日志记录系统,也不能将自己更改为 Auditor 或 SuperUser 角色。
超级用户
SuperUser 角色没有任何限制,并且可以完全访问服务器的所有资源和操作,包括审计日志记录系统。如果禁用 RBAC,则所有管理用户都具有等同于 SuperUser 角色的权限。
deployer
Deployer 角色具有与 monitor 相同的权限,但它可以修改部署的配置和状态,以及启用为应用资源的任何其他资源类型。
审核员
Auditor 角色具有 monitor 角色的所有权限,也可查看敏感数据,但不能修改。它对审计日志记录系统具有完全访问权限。Auditor 角色是 SuperUser 之外的唯一角色,它可以访问审计日志记录系统。审核员 无法修改敏感数据或资源。仅允许读取访问权限。

权限

权限 决定了每个角色可以做什么,不是每个角色都有每个权限。值得注意的是,SuperUser 具有每个权限,而 monitor 具有最少权限。每个权限都可以授予一组资源的读取和写入访问权限。类别为运行时状态、服务器配置、敏感数据、审计日志和访问控制系统。

表 2.1. Monitor、Operator、totainer 和 Deployer 的每个角色的权限

 MonitorOperatorMaintainerdeployer

读取配置和状态

阅读敏感数据 2

    

修改敏感数据 2

    

读取/修改审计日志

    

修改运行时状态

 

1

修改持久配置

  

1

读取/修改访问控制

    

1 权限仅限于应用程序资源。

表 2.2. 审核员、管理和超级用户的每个角色的权限

 审核员Administrator超级用户

读取配置和状态

阅读敏感数据 2

修改敏感数据 2

 

读取/修改审计日志

 

修改运行时状态

 

修改持久配置

 

读取/修改访问控制

 

2 哪些资源被视为敏感数据,它们使用敏感度进行配置。

约束(constraint)

约束是指定资源的 access-control 配置集。RBAC 系统使用限制和角色权限的组合来确定任何特定用户是否可以执行管理操作。

限制分为三种分类:

应用程序约束
应用约束定义可由 Deployer 用户访问的资源和属性集合。默认情况下,唯一启用的应用程序约束是 core,其中包括部署和部署覆盖。还包含了对数据源、日志记录、邮件、消息传递、命名、资源适配器和安全性的应用程序限制,但默认情况下不启用。这些限制不仅允许 Deployer 用户部署应用,还能够配置和维护这些应用所需的资源。
敏感度限制
敏感度限制定义一组被视为敏感的资源。敏感资源通常是机密(如密码)或将对服务器运行有严重影响的资源,如联网、JVM 配置或系统属性。访问控制系统本身也被视为敏感。允许写入敏感资源的唯一角色是 Administrator 和 SuperUser。Auditor 角色只能读取敏感资源。其他角色没有访问权限。
Vault Expression 约束
vault 表达式约束定义读取和写入 vault 表达式是否被视为敏感操作。默认情况下,读取和写入 vault 表达式是敏感的操作。

2.4.1. 配置 RBAC

如果已经启用了 RBAC,则必须分配 SuperUserAdministrator 角色,以便在用户或组级别进行配置更改。

流程

  1. 使用以下命令启用 RBAC:

    /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
  2. 作为 JBoss EAP 的 SuperUser管理员,配置 RBAC:

    • 要添加其中一个支持的角色,如具有只读权限的 Monitor 角色,请使用以下命令:

      /core-service=management/access=authorization/role-mapping=Monitor:add()
      注意

      有关 monitor 角色和其他您可以添加角色的更多信息,请参阅基于角色的访问控制。

    • 要将用户添加到特定角色,如 Monitor 角色,请使用以下命令:

      /core-service=management/access=authorization/role-mapping=Monitor/include=user-timRO:add(name=timRO,type=USER)
    • 要在特定角色(如 Monitor 角色)中添加组,请使用以下命令:

      /core-service=management/access=authorization/role-mapping=Monitor/include=group-LDAP_MONITORS:add(name=LDAP_MONITORS, type=GROUP)
    • 要从特定角色中排除用户或组,请使用以下命令:

      /core-service=management/access=authorization/role-mapping=Monitor/exclude=group-LDAP_MONITORS:add(name=LDAP_, type=GROUP)
  3. 重启服务器或主机以启用它与 RBAC 配置操作:

    • 要重启主机机器,请使用以下命令:

      reload --host=master
    • 要在独立模式中重启服务器,请使用以下命令:

      reload

2.5. 声明性安全和 Jakarta 身份验证

声明性安全性是通过利用容器管理安全性的方法将安全性问题与应用代码分开。容器根据文件权限或用户、组和角色提供授权系统。这种方法通常优于编程安全性,这使得应用本身都负责安全性。JBoss EAP 通过在 security 子系统中使用安全域来提供声明性安全性。

Jakarta 身份验证是一个声明性安全 API,由一组 Java 软件包组成,专为用户身份验证和授权设计。API 是标准可插拔验证模块(PAM)框架的 Java 实施。它扩展了 Jakarta EE 访问控制架构,以支持基于用户的授权。JBoss EAP 安全 子系统实际上基于 Jakarta 身份验证 API。

由于 Jakarta 身份验证是 安全 子系统的基础,因此身份验证以可插拔方式执行。这允许 Java 应用独立于底层身份验证技术,如 Kerberos 或 LDAP,并允许安全管理器在不同的安全基础架构中工作。不更改安全管理器实施,即可实现与安全基础架构的集成。仅需要更改 Jakarta 身份验证使用的身份验证堆栈的配置。

2.6. Elytron 子系统

JBoss EAP 7.1 中引入了 elytron 子系统。它以 WildFly Elytron 项目为基础,该项目是一种安全框架,用于统一整个应用服务器的安全性。elytron 子系统启用单一配置,以同时保护应用和管理接口。WildFly Elytron 还提供一组 API 和 SPI,用于提供自定义功能实施并与 elytron 子系统集成。

此外,WildFly Elytron 还有一些其他重要功能:

  • 更强大的 HTTP 和 SASL 身份验证机制.
  • 改进的架构允许在 安全域 之间传播安全身份。这确保了可用于授权的透明转换。这种转换利用可配置的角色解码器、角色映射器和权限映射器进行。
  • SSL/TLS 配置的集中点,包括密码套件和协议。
  • SSL/TLS 优化,如及时 的安全智能 结构,以及建立 SSL/TLS 连接的紧密关联授权。近日 安全身份构建 消除了基于每个请求 构建安全 身份的需要。通过紧密关联身份验证来建立 SSL/TLS 连接,可以实现收到第一个请求的 BEFORE 权限检查。
  • 个安全的凭证存储,用于替换前面的 vault 实施来存储纯文本字符串。

新的 elytron 子系统与传统 安全 子系统和旧版核心管理身份验证并行存在。传统和 Elytron 方法都可用于保护管理接口,并为应用提供安全性。

重要

基于 PicketBox 的 Elytron 和传统安全子系统的架构截然不同。Elytron 曾尝试创建一个解决方案,允许您在当前运行的同一安全环境中运行;然而,这并不表示每个 PicketBox 配置选项在 Elytron 中都有等同的配置选项。

如果您无法在文档中找到信息以帮助您使用旧版安全实施时获得类似功能,则可以通过以下方法之一找到帮助:

2.6.1. 核心概念和组件

elytron 子系统架构和设计背后的概念是使用较小的组件来组合完整的安全策略。默认情况下,JBoss EAP 提供许多组件的实施,但 elytron 子系统也允许您提供专用的自定义实施。

在"elytron"子系统中的每个组件实施都以单独的能力进行处理。这意味着,可以使用不同的资源混合、匹配和建模不同的实施。

2.6.1.1. 功能和要求

功能是 JBoss EAP 中使用的一种功能,可通过管理层来公开。个功能可以依赖于其他功能,这种依赖关系由管理层进行调和。些功能由 JBoss EAP 自动提供,但运行时可用的全部功能都使用 JBoss EAP 配置来确定。管理层验证服务器启动以及进行任何配置更改时是否存在其他功能所需的所有功能。功能与 JBoss 模块和扩展集成,但它们都是不同的概念。

除了注册它依赖的其他功能外,一个功能还必须注册与这些功能相关的一组要求。能力可以指定以下类型的要求:

硬要求
能力依赖于其他功能,因此必须始终存在。
可选要求
功能的可选方面取决于另一能力,这些功能可以也可以启用。因此,在分析配置前无法确定或知道此要求。
仅运行时要求
能力将检查运行时是否存在所需的能力。如果存在所需的能力,则将使用它。如果没有所需的能力,将不会使用它。

您可以在 WildFly 文档中找到有关功能和要求的更多信息

2.6.1.2. API、SPI 和自定义实施

Elytron 提供一组安全 API 和 SPI,以便其他子系统和使用者可以直接使用它们,从而降低集成开销。尽管大多数用户将使用 JBoss EAP 提供的功能,但 Elytron API 和 SPI 也可供自定义实施用于替换或扩展 Elytron 功能。

2.6.1.3. 安全域

安全域是安全策略的表示形式,由一个或多个安全域以及一组执行转换的资源提供支持。安全域将生成 SecurityIdentitySecurityIdentity 由执行授权的其他资源使用,如应用。SecurityIdentity 是当前用户的表示,它基于原始 授权身份及其 关联的角色和权限。

您还可以配置安全域,以允许 Security Identity from other 安全域的内向。当身份 流化 时,它会保留其原始 授权Identity,并为它分配一组新的角色和权限,从而创建一个新的 SecurityIdentity

重要

部署仅限于在每个部署中使用一个 Elytron 安全域。现在,可以使用一个 Elytron 安全域来完成可能需要多个传统安全域的情况。

2.6.1.4. Security Realms

安全域提供对身份存储的访问,用于获取凭据。这些凭据允许身份验证机制获取用于执行身份验证的原始 授权Identity。它们还允许验证机制在验证证据时执行验证。

您可以将一个或多个安全域与一个安全域关联。些安全域实施也公开用于修改的 API,这意味着安全域可以对底层身份存储进行更新。

2.6.1.5. 角色解码器

角色解码器与安全域关联,用于解码当前用户的角色。角色解码器取从安全域返回的原始 AuthorizationIdentity,并将其属性转换为角色。

2.6.1.6. 角色映射器

角色映射器将角色修改应用到身份。这可以从对角色格式进行规范化,到添加或删除特定角色等。角色映射器可以与安全域和安全域关联。如果角色映射器与安全域关联,则角色映射将在安全域级别上应用,然后才会在安全域级别上应用任何转换(如角色解码或额外的角色映射)。如果角色映射器和其他转换(如角色解码器)都在安全域中配置,则在应用角色映射器之前执行所有其他转换。

2.6.1.7. 权限映射器

权限映射器与安全域关联,并为 SecurityIdentity 分配一组权限。

2.6.1.8. 主体转换器

主要的转换器可用于 elytron 子系统内的多个位置。主体转换器可以转换或将名称映射到另一个名称。

2.6.1.9. 主体 Decoders

首席解码器可用于 elytron 子系统内的多个位置。主体解码器将身份从 Principal 转换为名称的字符串表示。例如,X500PrincipalDecoder 允许您将 X500Principal X500Principal 从证书的可分辨名称转换为字符串表示。

2.6.1.10. realm Mappers

域映射器与安全域关联,在安全域配置了多个安全域时使用。域映射器也可以与 http-authentication -factory 和 sasl-authentication-factory 的机制 或机制域 相关联。域映射器使用身份验证期间提供的名称来选择用于身份验证的安全域,并获取原始 授权 IDdentity

2.6.1.11. 身份验证事实

身份验证工厂是身份验证策略的表示形式。身份验证与安全域、机制工厂和机制选择器相关联。安全域提供要身份验证的 SecurityIdentity,机制工厂提供服务器端身份验证机制,而机制选择器则用于获取特定于所选机制的配置。机制选择器可以包含有关域名称的信息,如应向远程客户端提供的机制,以及身份验证过程中要使用的其他主体转换器和域映射器。

2.6.1.12. KeyStores

key-store 是密钥 存储或信任存储的定义,包括密钥存储的类型、其位置以及用于访问它的凭据。

2.6.1.13. 密钥管理器

key-manager 引用 密钥 存储,并与 SSL 上下文结合使用。

2.6.1.14. 信任管理器

trust-manager 引用作为信任存储(在 密钥存储 中定义),它与 SSL 上下文一起使用,通常用于双向 SSL/TLS。

2.6.1.15. SSL 上下文

elytron 子系统中定义的 SSL 上下文是一个 javax.net.ssl.SSLContext,这意味着它可供直接使用 SSL 上下文的任何对象使用。除了 SSL 上下文的常规配置外,还可以配置其他项目,如密码套件和协议。SSL 上下文将嵌套所配置的任何其他项目。

2.6.1.16. 安全凭证存储

之前的用于纯文本字符串加密的 vault 实施已被新设计的凭证存储替代。除了保护它存储的凭据外,凭据存储还用于存储纯文本字符串。

2.6.2. Elytron 身份验证流程

可以在 elytron 子系统内定义多个主体转换器、域映射器和一个主体解码器。以下小节讨论这些组件在身份验证过程中是如何发挥作用的,以及如何将主体映射到适当的安全域。

当一个主体被验证时,它会按顺序执行以下步骤:

  1. 确定和配置适当的机制配置。
  2. 传入的主体映射到 SecurityIdentity 中。
  3. 此安全性 用于确定适当的安全域。
  4. 确定安全域后,主体会再次转换。
  5. 最终转换发生,允许特定机制的转换。

下图演示了左侧列中突出显示的这些步骤,以及显示各个阶段中使用的组件。

图 2.1. Elytron 身份验证流程

Elytron 身份验证流程
预域映射

在预域映射期间,经过身份验证的主体映射到 SecurityIdentity,该表单可以识别应使用哪个安全域,并且将包含表示身份验证信息的单个 Principal。主体转换程序和主体解码器按以下顺序调用:

  1. 机制 Realm - pre-realm-principal-transformer
  2. 机制配置 - 预域-principal-transformer
  3. 安全域 - 主体decoderpre-realm-principal-transformer

如果这个过程导致 null 主体,则会抛出错误并终止身份验证。

图 2.2. 预域映射

预域映射
域名称映射

获取映射的主体后,将识别将用于加载身份的安全域。此时,realm 名称是由安全域定义的名称,也不是安全域的机制域名称。该配置会按照以下顺序查找安全域名:

  1. 机制 Realm - 域映射器
  2. 机制配置 - realm-mapper
  3. 安全域 - realm-mapper

如果 RealmMapper 返回 null,或者没有可用的映射器,则将使用安全域中的 default-realm

图 2.3. 域名称映射

域名称映射
安装后映射

在确定了某个领域后,主体将经历另一轮转换。转换器按以下顺序调用:

  1. 机制 Realm - 后域后转换器
  2. 机制配置 - 域后-principal-transformer
  3. 安全域 - realm-principal-transformer

如果这个过程导致 null 主体,则会抛出错误并终止身份验证。

图 2.4. 安装后映射

安装后映射
最终主要转换

最后,进行最后一类主要转换,允许特定机制的转换在特定领域转换前后应用。如果此阶段不需要,则可在域后映射阶段获得相同的结果。转换器按以下顺序调用:

  1. 机制 Realm - 最终主转换器
  2. 机制配置 - 最终的主转换器
  3. realm Mapping - principal-transformer

如果这个过程导致 null 主体,则会抛出错误并终止身份验证。

图 2.5. 最终主要转换

最终主要转换
获取 Realm 身份

最后一系列主体转换后,调用在域名映射中标识的安全域来获取用于继续身份验证的域身份

2.6.3. HTTP 身份验证

Elytron 提供一整套 HTTP 身份验证机制,包括 BASIC、FORMDIGESTSPNEGOCLIENT_CERT。HTTP 身份验证是使用 HttpAuthenticationFactory 进行处理的,它既是使用 HTTP 身份验证机制的身份验证策略,也是配置的身份验证机制的工厂。

HttpAuthenticationFactory 参考以下内容:

SecurityDomain
将对其执行任何机制身份验证的安全域。
HttpServerAuthenticationMechanismFactory
服务器端 HTTP 身份验证机制的一般工厂。
MechanismConfigurationSelector
您可以使用它为身份验证机制提供其他配置。mechanism ConfigurationSelector 的目的是获取特定于所选机制的配置。这包括有关应当向远程客户端提供的机制、其他主要转换器和身份验证过程中要使用的域映射器的域名信息。

2.6.4. SASL 身份验证

SASL 是一种身份验证框架,将身份验证机制本身与其使用的协议分开。它还允许使用其他身份验证机制,如 DIGEST-MD5、GSSAPIOTPSCRAM。SASL 身份验证不属于 Jakarta EE 规范。SASL 身份验证使用 SaslAuthenticationFactory 进行处理,SaslAuthenticationFactory 既是使用 SASL 身份验证机制的身份验证策略,又是用于配置身份验证机制的工厂。

SaslAuthenticationFactory 参考以下内容:

SecurityDomain
将对其执行任何机制身份验证的安全域。
SaslServerFactory
服务器端 SASL 验证机制的一般工厂。
MechanismConfigurationSelector
您可以使用它为身份验证机制提供其他配置。mechanism ConfigurationSelector 的目的是获取特定于所选机制的配置。这包括有关应当向远程客户端提供的机制、其他主要转换器和身份验证过程中要使用的域映射器的域名信息。

2.6.5. Elytron Subsystem 和 Legacy 系统间的交互

您可以将传统 安全 子系统组件以及旧版核心管理身份验证的一些主要组件映射到 Elytron 功能。这允许在基于 Elytron 的配置中使用这些旧组件,并允许从旧组件进行增量迁移。

2.6.6. Elytron 子系统中的资源

JBoss EAP 在 elytron 子系统中提供一组资源:

工厂
aggregate-http-server-mechanism-factory
HTTP 服务器工厂定义,其中 HTTP 服务器工厂是其他 HTTP 服务器工厂的聚合。
aggregate-sasl-server-factory
SASL 服务器工厂定义,其中 SASL 服务器工厂是其他 SASL 服务器工厂的聚合。
configurable-http-server-mechanism-factory
HTTP 服务器工厂定义,它将包装另一个 HTTP 服务器工厂并应用指定的配置和过滤。
configurable-sasl-server-factory
SASL 服务器工厂定义,打包另一个 SASL 服务器工厂并应用指定的配置和过滤。
custom-credential-security-factory
自定义凭据 SecurityFactory 定义。
http-authentication-factory

包含安全域与 HttpServerAuthenticationMechanismFactory 关联 的资源.

如需更多信息,请参阅 如何使用 证书 配置 JBoss EAP 身份管理

kerberos-security-factory

用于获取用于身份验证期间使用的 GSSCredential 的安全工厂。

如需更多信息,请参阅如何为 JBoss EAP 使用 Kerberos 设置 SSO 配置 Elytron 子系统

mechanism-provider-filtering-sasl-server-factory
SASL 服务器工厂定义,允许供应商过滤该工厂,其中使用提供程序加载工厂。
provider-http-server-mechanism-factory
HTTP 服务器工厂定义,其中 HTTP 服务器工厂是来自提供程序列表中的工厂聚合。
provider-sasl-server-factory
SASL 服务器工厂定义,其中 SASL 服务器工厂是来自提供程序列表中的工厂聚合。
sasl-authentication-factory

包含安全域与 SASL 服务器工厂关联的资源。

如需更多信息,请参阅如何为 JBoss EAP 配置服务器安全性 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/how_to_configure_server_security/#elytron_secure_mgmt_new_identity_store 中的新身份服务的安全管理接口

service-loader-http-server-mechanism-factory
HTTP 服务器工厂定义,其中 HTTP 服务器工厂是利用 ServiceLoader 标识的工厂的聚合。
service-loader-sasl-server-factory
SASL 服务器工厂定义,其中 SASL 服务器工厂是通过 ServiceLoader 识别的工厂聚合。
主体转换器
aggregate-principal-transformer
单个转换器试图转换原始主体,直到返回一个非空主体。
chained-principal-transformer
典型的转换器定义,主体转换器是其他主要转换器的串联。
constant-principal-transformer
主流转换器定义,主体转换器始终返回相同的常量。
custom-principal-transformer
自定义主体转换器定义.
regex-principal-transformer
基于正则表达式的主体转换器.
regex-validating-principal-transformer
基于正则表达式的主体转换器,它使用正则表达式来验证名称。
主体 Decoders
aggregate-principal-decoder
一个主要的解码器定义,其中主体解码器是其他主体解码器的聚合。
concatenating-principal-decoder
一个主要的解码器定义,其中主体解码器是其他主体解码器的串联。
constant-principal-decoder
定义始终返回相同常数的主要解码器。
custom-principal-decoder
自定义主体解码器的定义。
x500-attribute-principal-decoder

定义基于 X500 属性的主体解码器。

如需更多信息,请参阅 如何使用 证书 配置 JBoss EAP 身份管理

x509-subject-alternative-name-evidence-decoder

在 X.509 证书中使用主题替代名称扩展作为主体的证明解码器。

如需更多信息,请参阅如何使用主题备用名称扩展配置 X.509 证书的 Evidence Decoder ,以了解如何为 JBoss EAP 配置服务器安全性

realm Mappers
constant-realm-mapper
始终返回相同值的恒定域映射器的定义。
custom-realm-mapper
自定义域映射器的定义.
mapped-regex-realm-mapper
首先使用正则表达式提取域名称的域映射器实施的定义,然后使用配置的域名映射进行转换。
simple-regex-realm-mapper
定义一个尝试使用正则表达式中的捕获组提取域名的简单域映射器(如果未提供匹配项),则改为使用委派域映射器。
realm
aggregate-realm

域定义是两个域的聚合,一个用于身份验证步骤,另一个用于加载授权步骤的身份。

注意

导出的传统安全域不能用作 aggregate-realm 的授权步骤的 Elytron 安全域

caching-realm

启用缓存到另一安全域的 realm 定义。缓存策略是 Least Recently Used,在达到最大条目数时,访问最少的条目将被丢弃。

如需更多信息,请参阅如何在 为 JBoss EAP 配置身份管理 中为安全性 Realms 设置缓存

custom-modifiable-realm
配置为可修改的自定义域预期将实施 Mod ableSecurityRealm 接口。通过将域配置为可修改的管理操作,将可用于操作该域。
custom-realm
自定义域定义可以实施 s SecurityRealm 接口或 Mod ibleSecurityRealm 接口。无论实施了哪一个接口,都不会公开用于管理域。但是,依赖该域的其他服务仍能够执行类型检查和投射,以获取修改 API 的访问权限。
filesystem-realm

由文件系统支持的简单安全域定义。

如需更多信息,请参阅如何在如何为 JBoss EAP 配置身份管理中,使用基于文件系统的用户身份 存储 配置身份验证。

identity-realm
在管理模型中表示身份的安全域定义。
jdbc-realm

由使用 JDBC 的数据库支持的安全域定义。

如需更多信息,请参阅如何在如何为 JBoss EAP 配置身份管理中,使用基于数据库的用户身份 存储 配置身份验证。

key-store-realm

由密钥存储支持的安全域定义。

如需更多信息,请参阅 如何使用 证书 配置 JBoss EAP 身份管理

ldap-realm

LDAP 支持的安全域定义。

如需更多信息,请参阅如何在如何为 JBoss EAP 配置身份管理中,使用基于 LDAP 的 Identity Store 配置身份验证。

properties-realm

由属性文件支持的安全域定义。

使用基于属性文件的身份存储配置身份验证以如何为 JBoss EAP 配置身份管理

token-realm
种安全域定义,能够从安全令牌验证和提取身份。
权限映射器
custom-permission-mapper
自定义权限映射器的定义.
logical-permission-mapper
逻辑权限映射器的定义.
simple-permission-mapper
定义简单配置的权限映射器.
constant-permission-mapper
始终返回相同常量的权限映射器的定义。
角色解码器
custom-role-decoder
自定义 RoleDecoder 的定义.
simple-role-decoder
定义一个简单的 RoleDecoder,该角色采用单个属性并将其直接映射到角色。
source-address-role-decoder
定义 source-address-role-decoder,它将角色根据客户端的 IP 地址分配给身份。
aggregate-role-decoder

聚合了两个或多个角色解码器返回的角色的 aggregate-role-decoder 定义。

如需更多信息,请参阅如何在如何为 JBoss EAP 配置身份管理中,使用基于文件系统的用户身份 存储 配置身份验证。

角色映射器
add-prefix-role-mapper
角色映射器的角色映射器定义,它为每个提供的每一提供添加前缀。
add-suffix-role-mapper
角色映射器的角色映射器定义,每个提供的后缀都会添加后缀。
aggregate-role-mapper
角色映射器定义,其中角色映射器是其他角色映射器的聚合。
constant-role-mapper

角色映射器定义,始终返回一组恒定角色。

如需更多信息,请参阅 如何使用 证书 配置 JBoss EAP 身份管理

custom-role-mapper
自定义角色映射器的定义.
logical-role-mapper
角色映射器的角色映射器定义,该定义使用两个引用的角色映射器执行逻辑操作。
mapped-role-mapper
角色映射器的角色映射器定义,该映射器使用预配置的角色名称映射器映射器。
regex-role-mapper

角色映射程序定义,角色映射程序使用正则表达式来转换角色。例如,您可以把 "app-admin", "app-operator" 分别映射到 "admin" 和 "operator"。

如需更多信息,请参阅 regex-role-mapper 属性

SSL 组件
client-ssl-context

用于连接客户端的 SSLContext。

如需更多信息,请参阅如何为 JBoss EAP 配置服务器 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/how_to_configure_server_security/#using_client_ssl_context 安全性中的客户端-ssl-context

filtering-key-store

过滤密钥存储定义,它通过过滤密钥存储 来提供密钥存储

如需更多信息,请参阅如何为 JBoss EAP 配置服务器安全性 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/how_to_configure_server_security/#using_filtering_key_store 的过滤密钥存储

key-manager

用于创建密钥管理器列表的关键管理器定义,以用于创建 SSL 上下文。

如需更多信息,请参阅如何使用 Elytron 子系统为管理接口启用单向 SSL/TLS ,了解如何为 JBoss EAP 配置服务器安全性

key-store

密钥存储定义.

如需更多信息,请参阅如何使用 Elytron 子系统为管理接口启用单向 SSL/TLS ,了解如何为 JBoss EAP 配置服务器安全性

ldap-key-store

LDAP 密钥存储定义,它将从 LDAP 服务器加载密钥存储。

如需更多信息,请参阅如何为 JBoss EAP 配置服务器安全性的使用 ldap-key-store

server-ssl-context

用于连接的服务器端的 SSL 上下文。

如需更多信息,请参阅如何使用 Elytron 子系统为管理接口启用单向 SSL/TLS ,了解如何为 JBoss EAP 配置服务器安全性

trust-manager

用于创建 TrustManager 列表的信任管理器定义,用于创建 SSL 上下文。

如需更多信息,请参阅如何使用 Elytron 子系统为管理接口启用双向 SSL/TLS ,了解如何为 JBoss EAP 配置服务器安全性

其他
aggregate-providers
由两个或多个 提供商加载器 资源的聚合。
身份验证配置
单个身份验证配置定义,供部署到 JBoss EAP 和其他资源的客户端在进行远程连接时用于进行身份验证。
authentication-context
单个身份验证上下文定义,用于在部署至 JBoss EAP 的客户端和其他资源进行远程连接时,提供 ssl -context 和身份验证配置
credential-store

凭据存储来为敏感信息(如外部服务的密码)保留别名。

如需更多信息,请参阅如何为 JBoss EAP 配置服务器安全性 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/how_to_configure_server_security/#cred_store_create 创建凭据存储

dir-context

用于连接到目录(LDAP)服务器的配置。

如需更多信息,请参阅如何为 JBoss EAP 配置服务器安全性的使用 ldap-key-store

provider-loader
提供商加载器的定义。
security-domain

安全域定义。

如需更多信息,请参阅 如何使用 证书 配置 JBoss EAP 身份管理

security-property
要设置的安全属性的定义。

2.7. 核心管理身份验证

核心管理身份验证负责使用 ManagementRealm 保护管理接口 HTTP 和原生的管理功能。它内置在核心管理中,默认启用和配置为核心服务。它仅负责确保管理接口的安全。

2.7.1. Security Realms

安全域是用户名、密码和组成员资格信息的身份存储,可用于对 Jakarta 企业 Bean、Web 应用和管理界面中的用户进行身份验证。最初,JBoss EAP 默认预配置了两个安全域: ManagementRealmApplicationRealm。两个安全域都使用 文件系统来存储用户和密码与用户和组成员资格信息之间的映射。默认情况下,它们在验证时使用摘要机制。

摘要机制是一种身份验证机制,它利用由多种信息组成的一次性单向哈希(包括用户名和密码映射属性文件中存储的信息)来验证用户。这使得 JBoss EAP 无需通过网络以纯文本形式发送任何密码,即可对用户进行身份验证。

JBoss EAP 安装包含一个脚本,可供管理员向两个域添加用户。以这种方式添加用户时,用户名和密码属性文件中存储用户名和密码密码。当用户尝试进行身份验证时,JBoss EAP 会将一次性使用编号 nonce 发回给客户端。然后,客户端使用用户名、密码、非ce 和一些其他字段生成单向哈希,并将用户名、非ce 和单向哈希发送到 JBoss EAP。JBoss EAP 查找用户预哈希的密码并使用该密码以及提供的用户名、非ce 和其他一些字段,以相同的方式生成另一个单向哈希。如果两端都使用相同的信息,包括正确的密码,哈希将匹配,用户通过身份验证。

虽然安全域默认使用摘要机制,但可以重新配置它们以使用其他身份验证机制。启动时,管理界面根据 ManagementRealm 中配置了哪些身份验证机制来确定将启用哪些身份验证机制。

安全域不涉及任何授权决策;但它们可以配置为加载用户组成员资格信息,随后可用于做出授权决策。用户通过身份验证后,将执行第二个步骤,以根据用户名加载组成员资格信息。

默认情况下,ManagementRealm 在管理接口的身份验证和授权中使用。ApplicationRealm 是默认的域,供 Web 应用和 Jakarta 企业 Bean 在验证和授权用户使用。

2.7.2. 默认安全性

默认情况下,核心管理身份验证以两种不同的形式保护 HTTP 和原生管理接口:本地客户端和远程客户端,它们默认配置为 ManagementRealm 安全 域。这些默认值可以不同配置或完全替换。

注意

开箱即用的管理接口配置为使用简单的访问控制,这不使用角色。因此,默认情况下,在使用简单访问控制时,所有用户都具有与 SuperUser 角色相同的特权,后者基本上可以访问所有内容。

2.7.2.1. 使用原生接口进行本地和远程客户端身份验证

原生接口或管理 CLI 可以在与运行 JBoss EAP 实例相同的主机上本地调用,或者从另一台计算机远程调用。尝试使用原生接口进行连接时,JBoss EAP 为客户端提供可用 SASL 身份验证机制的列表,如 本地 jboss 用户、BASIC 等。客户端选择其所需的身份验证机制,并尝试通过 JBoss EAP 实例进行身份验证。如果失败,它将使用任何剩余的机制重试或停止尝试连接。本地客户端可以选择使用 本地 jboss 用户身份验证 机制。这种安全机制基于客户端访问本地文件系统的能力。它验证尝试登录的用户实际上是否能够访问与 JBoss EAP 实例相同的主机上的本地文件系统。

这个验证机制会出现在四个步骤中:

  1. 客户端向服务器发送一条消息,其中包含使用 本地 jboss 用户 进行身份验证的请求。
  2. 服务器生成一次性令牌,将其写入唯一文件,然后向客户端发送一条包含文件完整路径的消息。
  3. 客户端从 文件读取令牌并将其发送到服务器,验证它对文件系统具有本地访问权限。
  4. 服务器验证令牌,然后删除 文件。

这种身份验证形式基于以下原则:如果实现对文件系统的物理访问,其他安全机制就是多余的。其原因是,如果用户具有本地文件系统访问权限,该用户有足够的访问权限来创建新用户,或者破坏其他安全机制。这有时被称为静默身份验证,因为它允许本地用户在不提供用户名或密码身份验证的情况下访问管理 CLI。

启用此功能是为了方便和协助本地用户运行管理 CLI 脚本,而无需额外的身份验证。这是一个非常有用的功能,因为本地配置的访问通常也让用户能够添加自己的用户详细信息或者以其他方式禁用安全检查。

也可以从其他服务器(甚至与远程客户端相同的服务器)访问原生接口。将原生接口作为远程客户端访问时,客户端将无法使用 本地 jboss 用户 进行身份验证,并且将强制使用其他身份验证机制,如 DIGEST。如果本地客户端无法使用 本地 jboss 用户 进行身份验证,它将自动回退并尝试将其他机制用作远程客户端。

注意

管理 CLI 可以从其他服务器调用,甚至使用与原生接口相反的 HTTP 接口。所有 HTTP 连接(CLI 或其他)都被视为远程连接,不包含在本地接口身份验证中

重要

默认情况下,原生接口不会被配置,所有管理 CLI 流量都由 HTTP 接口处理。JBoss EAP 7 支持 HTTP 升级,它允许客户端通过 HTTP 进行初始连接,然后发送请求将该连接升级到另一协议。对于管理 CLI,将通过 HTTP 向 HTTP 接口发出初始请求,但随后连接会升级到原生协议。此连接仍然通过 HTTP 接口处理,但它使用原生协议进行通信,而不是 HTTP。或者,如果需要,仍可启用和使用原生接口。

2.7.2.2. 使用 HTTP 接口进行本地和远程客户端身份验证

HTTP 接口可以由与运行 JBoss EAP 实例相同的主机上的客户端在本地调用,或者由客户端从另一台计算机远程调用。尽管允许本地和远程客户端访问 HTTP 接口,但访问 HTTP 接口的所有客户端都将被视为远程连接。

当客户端尝试连接 HTTP 管理接口时,JBoss EAP 会发回 HTTP 响应,其状态代码为 401 Unauthorized,还有一组列出受支持的身份验证机制的标头,如 Digest、GSSAPI 等。Digest 的标头还包括 JBoss EAP 生成的非ce。客户端查看标题并选择要使用的身份验证方法,并发送相应的响应。如果客户端选择 Digest,则会提示用户输入其用户名和密码。客户端使用提供的字段,如用户名和密码、非ce 以及一些其他信息片段来生成单向哈希。客户端随后将单向哈希、用户名和非作为响应发送到 JBoss EAP。JBoss EAP 采用该信息、生成另一个单向哈希,比较这两者并根据结果对用户进行身份验证。

2.7.3. 高级安全性

可以通过多种方式更改管理接口的默认配置,以及身份验证和授权机制,从而影响其保护方式。

2.7.3.1. 更新管理接口

除了修改身份验证和授权机制外,JBoss EAP 还允许管理员更新管理接口本身的配置。有许多选项:

配置管理接口以使用单向 SSL/TLS
仅使用单向 SSL/TLS 配置 JBoss EAP 管理控制台以进行通信可提高安全性。客户端和管理控制台之间的所有网络流量都加密,这降低了安全攻击的风险,比如中间人攻击的风险。管理 JBoss EAP 实例的任何人都拥有比非特权用户更高的权限,使用单向 SSL/TLS 有助于保护该实例的完整性和可用性。使用 JBoss EAP 配置单向 SSL/TLS 时,权威签名证书优先于自签名证书,因为它们提供信任链。允许自签名证书,但不建议使用。
使用双向 SSL/TLS
双向 SSL/TLS 身份验证(也称为客户端身份验证)使用 SSL/TLS 证书验证客户端和服务器。这不仅保证了它所说的服务器,而且客户端也是它的描述。
更新或创建新安全域
可以使用新的安全域更新或替换默认安全域。

2.7.3.2. 添加出站连接

些安全域连接到外部接口,如 LDAP 服务器。出站连接定义了如何进行此连接。预定义的连接类型 ldap-connection 设置所有必填和可选属性,以连接到 LDAP 服务器并验证凭据。

2.7.3.3. 在管理接口中添加 RBAC

默认情况下禁用 RBAC 系统。它通过从 简单的 to rbac 更改 provider 属性来 启用。这可以通过管理 CLI 来完成。在运行的服务器上禁用或启用 RBAC 时,必须先重新加载服务器配置才能生效。

为管理接口启用 RBAC 时,分配给用户的角色决定了他们有权访问的资源,以及他们可使用资源属性执行的操作。只有 AdministratorSuperUser 角色的用户才能查看和更改访问控制系统。

警告

在没有正确配置用户和角色的情况下启用 RBAC 可能会导致管理员无法登录到管理界面。

RBAC 在管理控制台中的影响

在管理控制台中,一些控件和视图被禁用,显示为灰显或根本不可见,具体取决于分配给用户的角色的权限。

如果用户对资源属性没有读取权限,则控制台中该属性将显示为空。例如,大多数角色无法读取数据源的用户名和密码字段。

如果用户具有读取权限,但没有对资源属性具有写入权限,则该属性将在资源的编辑表单中禁用。如果用户没有资源写入权限,则不会出现资源的编辑按钮。

如果用户没有访问资源或属性的权限,这意味着该角色无法寻址,则不会出现在该用户的控制台中。其中的一个示例是访问控制系统本身,它默认仅对几个角色可见。

管理控制台还为以下常见 RBAC 任务提供了一个接口:

  • 查看和配置为每个用户分配或排除的角色。
  • 查看并配置为每个组分配或排除哪些角色。
  • 查看每个角色的组和用户成员资格。
  • 每个角色配置默认成员资格。
  • 创建有作用域角色。
注意

目前无法在管理控制台中配置限制。

RBAC 对管理 CLI 或管理 API 的影响

启用 RBAC 时,管理 CLI 或管理 API 的用户的行为略有不同。

无法读取的资源和属性会根据结果进行过滤。如果过滤过的项目可以被角色寻址,则在结果的 response -headers 部分中将其名称列为 filtered- attributes。如果资源或属性不能被角色寻址,则它不会被列出。

尝试访问不可寻址的资源将导致 Resource Not Found 错误。

如果用户尝试写入或读取他们可以寻址的资源,但缺少适当的写入或读取权限,则返回 Permission Denied 错误。

管理 CLI 可以执行与管理控制台相同的所有 RBAC 任务,以及一些额外的任务:

  • 启用和禁用 RBAC
  • 更改权限组合策略
  • 配置应用程序资源和资源敏感度限制

RBAC 对 Jakarta 管理的 Bean 的影响

基于角色的访问控制通过三种方式应用到 Jakarta 管理:

  1. JBoss EAP 的管理 API 公开为 Jakarta 管理 Bean。这些受管 Bean 称为 核心组件, 它们的访问会被控制和过滤,与底层管理 API 本身完全相同。
  2. jmx 子系统配置有敏感写入权限。这意味着只有 AdministratorSuperUser 角色的用户 才可以对该子系统进行更改。Auditor 角色的用户也可以读取此子系统配置。
  3. 默认情况下,所有管理用户可以访问由已部署的应用程序和服务或非核心 MBeans 注册的 Bean,但只有 MaintainerOperatorAdministratorSuperUser 角色的用户 可以向其写入。

RBAC 身份验证

RBAC 与 JBoss EAP 附带的标准身份验证提供商一同工作:

用户名/密码
用户通过用户名和密码组合进行验证,该组合通过 ManagementRealm 的设置进行验证,该设置可以使用本地属性文件或 LDAP。
客户端证书
truststore 为客户端证书提供身份验证信息。
本地 jboss 用户
如果服务器在同一计算机上运行,则 jboss-cli 脚本会自动以本地 jboss 用户 进行身份验证。默认情况下,本地 jboss 用户SuperUser 组的成员。

无论使用了何种提供程序,JBoss EAP 均负责将角色分配给用户。通过 ManagementRealm 或 LDAP 服务器进行身份验证时,这些系统可以提供用户组信息。JBoss EAP 还可以使用此信息将角色分配给用户。

2.7.3.4. 将 LDAP 与管理接口搭配使用

JBoss EAP 包含多个身份验证和授权模块,允许 LDAP 服务器用作 Web 和 Jakarta Enterprise Beans 应用的身份验证和授权授权。

要使用 LDAP 目录服务器作为管理控制台、管理 CLI 或管理 API 的身份验证源,必须执行以下任务:

  1. 创建与 LDAP 服务器的出站连接。
  2. 创建支持 LDAP 的安全域或更新现有安全域以使用 LDAP。
  3. 在管理界面中引用新的安全域。

LDAP 身份验证器首先建立与远程目录服务器的连接即可运行。然后,使用用户传递给身份验证系统的用户名执行搜索,以查找 LDAP 记录的完全限定区分名称(DN)。使用用户的 DN 作为用户提供的凭据和密码,建立与 LDAP 服务器的新连接。如果对 LDAP 服务器的此身份验证成功,则 DN 被验证为有效。

创建支持 LDAP 的安全域后,管理界面可以引用它。管理接口将使用安全域进行身份验证。JBoss EAP 也可以配置为使用 LDAP 服务器的出站连接,利用双向 SSL/TLS 在管理界面和管理 CLI 中进行身份验证。

2.7.3.5. Jakarta 身份验证和管理接口

Jakarta 身份验证可用于保护管理接口。将 Jakarta 身份验证用于管理接口时,必须将安全域配置为使用安全域。这引入了核心服务和子系统之间的依赖关系。虽然不需要使用 Jakarta Authentication 来保护管理接口,但建议管理员启用 SSL/TLS,以避免以不安全的方式意外传输敏感信息。

注意

当 JBoss EAP 实例以 仅管理员 模式运行时,不支持使用 Jakarta 身份验证来保护管理接口。如需有关 仅限管理员 模式的更多信息,请参阅 JBoss EAP 配置指南 中的仅管理模式运行 JBoss EAP。

2.8. 安全子系统

security 子系统为应用提供安全基础架构,它基于 Jakarta 身份验证 API。该子系统使用与当前请求关联的安全上下文,以公开身份验证管理器、授权管理器、审计管理器和将管理器映射到相关容器的功能。

身份验证和授权管理器处理身份验证和授权。在将信息传递给应用之前,映射管理器处理从主体、角色或属性添加、修改或删除信息。审计管理器允许用户配置供应商模块,以控制报告安全事件的方式。

在大多数情况下,管理员应仅关注设置和配置安全域,以更新 security 子系统的配置。在安全域外,唯一可能需要更改的安全元素是 深度复制-subject-mode有关深度复制主题模式的更多信息,请参阅安全管理部分

2.8.1. 安全域

安全域是一组 Jakarta Authentication 声明性安全配置,供一个或多个应用用于控制身份验证、授权、审核和映射。默认包含以下四个安全域: jboss-ejb-policyjboss-web-policyotherja Alstjboss-ejb-policyjboss-web-policy 安全域是 JBoss EAP 实例的默认授权机制。如果应用配置的安全域不定义任何身份验证机制,将使用它们。这些安全域 以及其他,也在 JBoss EAP 内部用于授权,是正确运行所必需的。ja demandingst 安全域是一个简单的 Jakarta 身份验证安全域,用于开发目的。

安全域包含身份验证、授权、安全映射和审计的配置。安全域是 JBoss EAP 安全 子系统的一部分,并由域控制器或单机服务器集中管理。用户可以根据需要创建任意数量的安全域来满足应用的要求。

您也可以使用 cache-type 属性配置安全域要使用的身份验证缓存类型。如果删除了此属性,将不会使用任何缓存。此属性允许的值为 default 或 infinispan

Elytron 和 PicketBox 安全域之间的比较

个部署应当与单个 Elytron 安全域或一个或多个传统的 PicketBox 安全域关联。部署不应与这两者关联。这是无效的配置。

如果部署与多个 Elytron 安全域关联,而一个部署可以与多个传统安全域关联,则会出现例外。

注意

使用 PicketBox 时,安全域封装了对底层身份存储的访问和用于授权决策的映射。因此,需要具有不同存储的 PicketBox 用户才能将不同的安全域用于不同的源。

在 Elytron 中,这两个功能是分隔的。对存储的访问由安全域处理,授权的映射由安全域处理。

因此,需要独立 PicketBox 安全域的部署不一定需要独立的 Elytron 安全域。

2.8.2. 使用安全域和安全域

安全域和安全域可用于保护部署到 JBoss EAP 的 Web 应用。在确定是否应使用这两者时,务必要了解这两者之间的区别。

Web 应用和 Jakarta Enterprise Beans 部署只能直接使用安全域。它们利用从身份存储传递的身份信息,利用登录模块来执行实际身份验证和授权。安全域可以配置为将安全域用于身份信息;例如,其他 允许应用指定用于身份验证和获取授权信息的安全域。它们也可以配置为使用外部身份存储。Web 应用和 Jakarta 企业 Beans 部署无法配置为直接使用安全域进行身份验证。安全域也是 security 子系统的一部分,在核心服务之后加载。

只有核心管理(如管理接口和 Jakarta 企业 Bean 远程端点)才能直接使用安全域。它们是提供身份验证和授权信息的身份存储。它们也是核心服务,在启动任何子系统之前加载。开箱即用的安全域( ManagementRealmApplicationRealm )使用基于文件的简单身份验证机制,但它们可以配置为使用其他机制。

2.8.3. 安全审核

安全审计指的是触发事件,如写入日志,以响应 security 子系统内发生的事件。审计机制配置为安全域的一部分,以及身份验证、授权和安全映射详细信息。审计使用提供程序模块来控制安全性事件的报告方式。JBoss EAP 随附多个安全审计提供商,但可以使用自定义提供商。JBoss EAP 的核心管理也具有自己的安全审计和日志记录功能,这些功能单独配置,不属于 security 子系统的一部分。

2.8.4. 安全映射

安全映射增加了在身份验证或授权发生后(但在将信息传递给您的应用之前)结合身份验证和授权信息的功能。授权的角色、身份验证的主体或凭据(这些属性不是主体或角色)可以全部映射。角色映射用于在身份验证后添加、替换或删除角色到主题。主体映射用于在身份验证后修改主体。您可以使用凭证映射从外部系统转换属性,供应用使用。您还可以使用凭证映射来转换应用的属性,供外部系统使用。

2.8.5. 密码 Vault 系统

JBoss EAP 拥有一个密码库,用于加密敏感字符串,将它们存储在加密的密钥存储中,然后为应用和验证系统解密它们。在纯文本配置文件中,如 XML 部署描述符,有时需要指定密码和其他敏感信息。JBoss EAP 密码库可用于安全地存储敏感字符串,以在纯文本文件中使用。

2.8.6. 安全域配置

安全域在域控制器或单机服务器上集中配置。使用安全域时,可以将应用配置为使用安全域,而不是单独配置安全性。这允许用户和管理员利用相对的安全性

示例

这种配置结构的一个常见场景是在测试和生产环境之间移动应用程序的过程。如果应用单独配置了安全性,则可能需要在每次将其提升到新环境中(例如从测试环境到生产环境)时对其进行更新。如果该应用改为使用安全域,则各个环境中的 JBoss EAP 实例可以针对当前环境正确配置其安全域,允许应用利用安全域提供正确的安全配置。

2.8.6.1. 登录模块

JBoss EAP 包括多个捆绑登录模块,适合大多数在安全域中配置的用户管理角色。security 子系统提供一些核心登录模块,它们可以从关系数据库、LDAP 服务器或平面文件读取用户信息。除了这些核心登录模块外,JBoss EAP 还提供其他登录模块,提供满足自定义需求的用户信息和功能。

常用登录模块摘要

LDAP 登录模块
Ldap 登录模块是一种登录模块实施,可根据 LDAP 服务器进行身份验证。security 子系统使用连接信息(即 bindDN)连接到 LDAP 服务器,即 bindDN,其具有权限为 baseCtxDNrolesCtxDN 树搜索用户和角色,这通过 Java 命名和目录接口初始上下文提供。当用户尝试进行身份验证时,LDAP 登录模块将连接到 LDAP 服务器并将用户的凭据传递给 LDAP 服务器。身份验证成功后,会在 JBoss EAP 中为该用户创建 InitialLDAPContext,填充有该用户的角色。
LdapExtended Login Module
LdapExtended 登录模块搜索用户以及绑定身份验证的相关角色。角色以递归方式查询,并遵循 DN 来浏览分层角色结构。登录模块选项包括所选 LDAP Java 命名和目录接口提供商支持的任何选项。
UsersRoles 登录模块
UsersRoles login 模块是一个简单的登录模块,支持从 Java 属性文件加载的多个用户和用户角色。此登录模块的主要用途是利用应用部署的属性文件,轻松测试多个用户和角色的安全设置。
数据库登录模块
Database 登录模块是 JDBC 登录模块,支持身份验证和角色映射。如果用户名、密码和角色信息存储在关系数据库中,则使用此登录模块。这可以通过以预期格式提供对逻辑表的引用,包含主体和角色。
证书登录模块
证书登录模块基于 X509 证书对用户进行身份验证。此登录模块的典型用例是 Web 层中的 CLIENT-CERT 身份验证。此登录模块仅执行身份验证,并且必须与能够获取授权角色的另一登录模块相结合,以完全定义对安全 Web 或 Jakarta Enterprise Beans 组件的访问。此登录模块的两个子类是 CertRolesLoginModuleDatabaseCertLoginModule,扩展行为以从属性文件或数据库获取授权角色。
Identity Login 模块
Identity login 模块是一种简单的登录模块,可将硬编码的用户名关联到针对该模块进行身份验证的任何主题。它使用由 principal 选项指定的名称创建一个 SimplePrincipal 实例。如果需要为服务提供固定的身份,此登录模块非常有用。这也可以用于开发环境,以测试与给定主体和相关角色关联的安全性。
Runas loginin 模块
RunAs login 模块是一种帮助模块,可在身份验证登录阶段将 run-as 角色推送到堆栈;然后,它在提交或中止阶段从堆栈填充 run-as 角色。此登录模块的目的是为必须访问受保护资源才能执行其身份验证的其他登录模块提供角色,例如,访问安全 Jakarta Enterprise Beans 的登录模块。RunAs 登录模块必须在需要按角色建立的登录模块之前配置。
客户端登录模块
Client login 模块是登录模块的一种实施,供 JBoss 客户端在建立调用者身份和凭据时使用。这会创建一个新的 SecurityContext,为其分配一个主体和凭证,并将 SecurityContext 设置为 ThreadLocal 安全上下文。Client login 模块是客户端唯一支持建立当前线程调用者的机制。独立的客户端应用和服务器环境(充当 JBoss Jakarta Enterprise Beans 客户端)均未配置为以透明方式使用 JBoss EAP 安全 子系统,必须使用 Client 登录模块。
警告

此登录模块不执行任何身份验证。它只是将提供的登录信息复制到服务器 Jakarta Enterprise Beans 调用层,以便在服务器上随后进行身份验证。在 JBoss EAP 中,这仅支持将用户身份切换为 JVM 调用。远程客户端不支持它建立身份

SPNEGO 登录模块
SPNEGO 登录模块是一种登录模块,通过 KDC 建立呼叫人身份和凭证。该模块实施 SPNEGO,是 JBoss Negotiation 项目的一部分。此身份验证可以在与 AdvancedLdap 登录模块的链配置中使用,以允许与 LDAP 服务器协作。Web 应用还必须启用应用中的 NegotiationAuthenticator 以使用此登录模块。
RoleMapping Login Module
RoleMapping 登录模块支持将身份验证过程最终生成的角色映射到一个或多个声明角色。例如,如果身份验证过程确定用户 John 具有角色 ldapAdmin 和 testAdmin ,并且 web.xml 或 ejb-jar.xml 文件中定义的声明角色是 admin,则此登录模块会将 ldapAdmintestAdmin 角色映射到 John。RoleMapping 登录模块必须定义为登录模块配置的可选模块,因为它会改变之前映射角色的映射。
远程登录模块
远程登录模块检查当前正在通过远程连接进行身份验证的请求。如果使用远程接口收到请求,则该请求与身份验证过程中创建的身份关联。
RealmDirect 登录模块
RealmDirect 登录模块允许使用现有的安全域来制定身份验证和授权决策。配置后,此模块将使用引用的域来查找身份信息,以做出身份验证决策和映射用户角色。例如,JBoss EAP 随附的预配置 其他 安全域具有 RealmDirect 登录模块。如果此模块中没有引用任何域,则默认使用 ApplicationRealm 安全域。
自定义模块
如果与 JBoss EAP 安全框架捆绑的登录模块无法满足安全环境的需求,可以编写自定义登录模块实施。AuthenticationManager 需要主题主体集的特定使用模式。要编写与身份验证管理器搭配使用的登录模块,需要全面了解 Jakarta Authentication Subject 类的信息存储功能以及这些功能的预期用途。

经常使用 UnauthenticatedIdentity login 模块选项。在某些情况下,请求未以身份验证的格式收到。Unauthenticated Identity 是一个登录模块配置选项,它将特定身份(如 guest )分配给在没有相关身份验证信息发出的请求。这可用于允许未受保护的 servlet 在 Jakarta Enterprise Beans 上调用不需要特定角色的方法。此类主体没有关联的角色,只能访问与未选中的权限约束关联的不安全的 Jakarta Enterprise Beans 方法。

2.8.6.2. 密码堆栈

堆栈中的多个登录模块可以串联在一起,每一登录模块在身份验证期间提供凭据验证和角色分配。这适用于许多用例,但有时凭据验证和角色分配分散到多个用户管理存储中。

请考虑在中央 LDAP 服务器中管理用户的情况,以及特定于应用的角色存储在应用的关系数据库中。password-stacking 模块选项捕获了这一关系。

要使用密码堆栈,每个登录模块都应将 password-stacking 属性设置为 useFirstPass,它位于 <module-option> 部分中。如果上一配置用于密码堆栈的模块对用户进行了身份验证,所有其他堆栈模块将考虑用户通过身份验证,并且仅尝试为授权步骤提供一组角色。

password-stacking 选项设置为 useFirstPass 时,此模块首先在属性名称 javax.security.auth.login.namejavax.security.auth.login.password 下分别在登录模块共享状态映射下查找共享用户名和密码。

如果找到,这些属性将用作主要名称和密码。如果没有找到,则主体名称和密码由此登录模块设置,并分别存储在属性名称 javax.security.auth.login.namejavax.security.auth.login.password 下。

2.8.6.3. 密码哈希

大多数登录模块必须将客户端提供的密码与用户管理系统中存储的密码进行比较。这些模块通常使用纯文本密码,但可以将其配置为支持散列密码,以防止纯文本密码存储在服务器端。JBoss EAP 支持配置哈希算法、编码和字符集。它还定义何时对用户密码和存储密码进行哈希处理。

重要

红帽 JBoss 企业应用平台通用标准认证配置不支持比 SHA-256 更弱的哈希算法。

2.8.7. 安全管理

security 子系统的安全 管理部分用于覆盖 security 子系统的高级行为。每个设置都是可选的。除了深度复制主题模式外,这些设置通常都是更改的。

2.8.7.1. 深度复制模式

如果已禁用深度复制主题模式(默认为该模式),复制安全数据结构会引用原始数据结构,而不是复制整个数据结构。此行为效率更高,但是如果多个具有相同身份的线程通过清空或注销操作清除该对象,则容易出现数据损坏。

如果启用了深度复制主题模式,则生成数据结构的完整副本及其所有相关数据,只要它们标记为可克隆。这比线程更安全,但效率较低。

2.8.8. 其他组件

2.8.8.1. jakarta 身份验证

Jakarta Authentication 是 Java 应用程序的可插拔接口,在 Jakarta Authentication 规范中定义。除了 Jakarta 身份验证身份验证外,JBoss EAP 还允许使用 Jakarta 身份验证。Jakarta 身份验证身份验证使用安全域中的登录模块进行配置,这些模块可以堆栈。jaclaimst 安全域是一个简单的 Jakarta Authentication 安全域,默认包含在内用于开发目的。

基于 Web 的管理控制台提供以下操作来配置 Jakarta Authentication 模块:

  • add
  • edit
  • remove
  • reset

部署到 JBoss EAP 的应用要求在其部署描述符中配置一个特殊的身份验证器,以使用 Jakarta 身份验证安全域。

2.8.8.2. Jakarta 授权

Jakarta 授权标准定义容器与授权服务提供商之间的合同,从而实施供容器使用的供应商。有关规格的详情,请参阅 Jakarta Authorization 1.1 规范

JBoss EAP 在 security 子系统的安全功能内实施对 Jakarta 授权的支持。

2.8.8.3. Jakarta 安全

Jakarta Security 定义了用于身份验证和身份存储的可移植插件接口,以及提供编程安全性的可注入型 SecurityContext 接口。您可以使用这些 API 的内置实施,或者定义自定义实施。有关规格的详情,请参阅 Jakarta 安全规范

Jakarta Security API 在 elytron 子系统中提供,可通过管理 CLI 启用。如需更多信息,请参阅《开发指南》中的关于 Jakarta 安全 API

2.8.8.4. 关于 Fine-Grained Authorization 和 XACML

细粒度授权使管理员能够适应在授予模块访问权限的决策制定过程中不断变化的要求和多个变量。因此,精细的授权可能会变得复杂。

注意

JBoss EAP 不支持用于 Web 或 Jakarta 企业 Bean 的 XACML 绑定。

JBoss EAP 将 XACML 用作介质来实现细粒度授权。XACML 提供基于标准的解决方案,以实现细粒度授权的复杂性质。XACML 为决策制定定义了策略语言和架构。XACML 架构包含一个策略强制点(PEP),它可截获正常程序流中的任何请求,并请求 Policy Decision 点(PDP)根据与 PDP 关联的策略做出访问权限决策。PDP 评估 PEP 创建的 XACML 请求,并通过策略运行以做出以下访问决策之一:

ALLOW
访问权限获得批准。
拒绝
访问被拒绝。
INDETERMINATE
PDP 中出现错误。
NOTAPPLICABLE
请求中缺少一些属性,或者策略不匹配。

XACML 还具有以下特性:

  • oasis XACML v2.0 库
  • 基于 JAXB v2.0 的对象模型
  • 用于存储和检索 XACML 策略和属性的现有DB 集成

2.8.8.5. SSO

JBoss EAP 为使用 undertowinfinispan 子系统的集群和非集群 SSO 提供开箱即用的支持。这需要:

  • 配置的安全域处理身份验证和授权。
  • SSO in finispan 复制缓存。它存在于受管域的 ha 和 full-ha 配置文件中,或者通过将 standalone-ha.xmlstandalone-full-ha.xml 配置文件用于单机服务器。
  • 其中包含的 Web cache-container 和 SSO 复制缓存必须存在。
  • undertow 子系统需要配置为使用 SSO。
  • 共享 SSO 信息的每个应用必须配置为使用相同的安全域。

第 3 章 红帽 JBoss 企业应用平台 SSO 的其他用例

除了开箱即用功能外,JBoss EAP 还支持 SSO 的其他用例,包括 SAML(适用于浏览器的 SSO)、基于桌面的 SSO 和 SSO(通过安全令牌服务)。

3.1. 使用 SAML 基于浏览器的 SSO

在基于浏览器的 SSO 场景中,一个或多个 Web 应用(称为服务提供商)在中心式架构中连接到集中式身份提供程序。身份提供商(IDP)充当中央来源或 hub,用于所有服务提供商或 spoke 的身份和角色信息。当未经身份验证的用户尝试访问其中一个服务提供商时,该用户会被重定向到 IDP 来执行身份验证。IDP 验证用户,发布 SAML 令牌指定主体的角色,并将它们重定向到请求的服务提供商。从那里,SAML 令牌在所有关联的服务提供商上使用,以确定用户身份和访问权限。这种从服务提供商开始使用 SSO 的具体方法称为服务提供商发起的流。

与许多 SSO 系统一样,JBoss EAP 也使用 IDP 和 SP。这两个组件都启用在 JBoss EAP 实例中运行,并与 JBoss EAP security 子系统配合工作。SAML v2、基于 FORM 的 Web 应用安全性和 HTTP/POST 和 HTTP/Redirect 绑定也用于实施 SSO。

若要创建身份提供程序,可在 JBoss EAP 实例中创建安全域(如 idp-domain ),它定义身份验证和授权机制(如 LDAP 或数据库)以充当身份存储。Web 应用(如 IDP.war )配置为使用额外的模块( org.picketlink )以结合使用 IDP 和 idp-domain 并部署到相同的 JBoss EAP 实例。IDP.war 将充当身份提供程序。要创建服务提供商,将创建一个使用 SAML2LoginModule 作为身份验证机制的安全域,如 sp-domain。Web 应用(如 SP.war )配置为使用其他模块( org.picketlink ),并且包含使用 sp-domain 的服务提供商 valve。SP.war 已部署到配置了 sp-domain 的 JBoss EAP 实例,并且现在是服务供应商。此过程可以复制到一个或多个 SP,如 SP2.warSP3.war 等,也可在一个或多个 JBoss EAP 实例之间复制。

3.1.1. 身份提供商启动流

在大多数 SSO 场景中,SP 通过向 IDP 发送身份验证请求来启动流,后者将 SAML 响应发送到具有有效断言的 SP。这称为 SP 启动流。SAML 2.0 规范定义了另一个流,称为 IDP 启动或非请求的 Response 流。在这种情况下,服务提供商不会启动身份验证流来接收来自 IDP 的 SAML 响应。流程从 IDP 方面开始。旦通过身份验证,用户可以从列表中选择特定的 SP,并重定向到 SP 的 URL。不需要特殊配置来启用此流。

演练

  1. 用户 访问 IDP.
  2. IDP 认为没有 SAML 请求或响应,假设使用 SAML 的 IDP 启动流场景。
  3. IDP 要求用户进行身份验证。
  4. 身份验证后,IDP 会显示托管部分,用户通过此部分获得链接到所有 SP 应用程序的页面。
  5. 用户选择一个 SP 应用程序。
  6. IDP 在查询参数 SAML 响应中,使用 SAML 断言将用户重定向到 SP。
  7. SP 检查 SAML 断言并提供访问权限。

3.1.2. 全局注销

在一个 SP 中启动的全局注销会从 IDP 和所有 SP 注销用户。如果用户在执行全局注销后试图访问任何 SP 或 IDP 的安全部分,则必须重新进行身份验证。

3.2. 基于桌面的 SSO

基于桌面的 SSO 方案允许在桌面之间共享一个主体,通常由 Active DirectoryKerberos 服务器以及一组 Web 应用(即 SP)来共享。在本例中,桌面 IDP 充当 Web 应用程序的 IDP。

在典型的设置中,用户登录受 Active Directory 域管理的桌面。用户通过配置了 JBoss Negotiation 并在 JBoss EAP 上托管的 Web 浏览器访问 Web 应用。Web 浏览器将登录信息从用户的本地计算机传输到 Web 应用。JBoss EAP 将后台 GSS 消息与 Active Directory 或任何 Kerberos 服务器用于验证用户。这使得用户可以在 Web 应用中实现无缝 SSO。

要将基于桌面的 SSO 设置为 Web 应用的 IDP,需要创建一个连接 IDP 服务器的安全域。NegotiationAuthenticator 作为 valve 添加到所需 Web 应用程序,JBoss Negotiation 则添加到 SP 容器的类路径中。或者,也可以像基于浏览器的 SSO 方案设置 IDP,但将基于桌面的 SSO 提供程序用作身份存储。

3.3. 使用 STS 的 SSO

JBoss EAP 为 SP 提供多个登录模块,用于连接 STS。它还可以运行 STS(PicketLinkSTS)。更具体地说,PicketLinkSTS 定义了多个与其他安全令牌服务的接口,并提供扩展点。可以使用配置插入实施,并通过配置为某些属性指定默认值。这意味着 PicketLinkSTS 生成和管理安全令牌,但不发布特定类型的令牌。相反,它定义允许插入多个令牌提供程序的通用接口。因此,只要每种令牌类型的令牌提供程序存在,就可以将其配置为处理各种类型的令牌。它还指定安全令牌请求和响应消息的格式。

下列步骤是使用 JBoss EAP STS 时处理安全令牌请求的顺序。

  1. 客户端向 PicketLinkSTS 发送安全令牌请求。
  2. PicketLinkSTS 解析请求消息并生成 Jakarta XML Binding 对象模型。
  3. PicketLinkSTS 读取配置文件并根据需要创建 STSConfiguration 对象。它从配置中获取 WSTrustRequestHandler 的引用,并将请求处理委派给处理程序实例。
  4. 请求处理程序在需要时使用 STSConfiguration 来设置默认值,例如当请求没有指定令牌生命周期值时。
  5. WSTrustRequestHandler 创建 WSTrustRequestContext,并设置 Jakarta XML Binding 请求对象及其从 PicketLinkSTS 收到的调用者主体。
  6. WSTrustRequestHandler 使用 STSConfiguration 获取 SecurityTokenProvider,必须用于根据所请求的令牌类型来处理请求。它调用提供程序,并将构建的 WSTrustRequestContext 作为参数传递。
  7. SecurityTokenProvider 实例处理令牌请求,并将发布的令牌存储在请求上下文中。
  8. WSTrustRequestHandler 从上下文获取令牌,根据需要对其进行加密,并构建包含安全令牌的 WS-Trust 响应对象。
  9. PicketLinkSTS 指示请求处理程序生成的响应,并将它返回到客户端。

STS 登录模块(如 STSIssuingLoginModule、STSValidatingLoginModule、SAML2STSLoginModule 等)通常被配置为 JEE 容器安全设置的一部分,以使用 STS 来验证用户。STS 可以和登录模块位于同一个容器上,或者通过 Web 服务调用或其他技术远程访问。

第 4 章 Elytron 子系统示例方案

4.1. 来自 Box

默认情况下,JBoss EAP 提供预配置的组件:

ApplicationDomain
ApplicationDomain 安全域使用 ApplicationRealmgroups-to-roles 进行身份验证。它还使用 default-permission-mapper 来分配登录权限。
ApplicationRealm
ApplicationRealm 安全 域是一个属性域,它使用 application-users.properties 验证主体,并使用 application-roles.properties 分配角色。这些文件位于 jboss.server.config.dir 下,默认情况下,该文件映射到 EAP_HOME/standalone/configuration。它们也是与传统安全默认配置使用的相同文件。
application-http-authentication
application-http-authentication http-authentication-factory 可用于通过 HTTP 进行身份验证。它使用 全局 provider-http-server-mechanism-factory 来过滤身份验证机制,并使用 ApplicationDomain 验证主体。它接受 BASICFORM 验证机制,并将 BASIC 作为 Application Realm 公开给应用。
application-sasl-authentication
application-sasl-authentication sasl-authentication-factory 可用于使用 SASL 进行身份验证。它使用 配置的 sasl-server-factory 来过滤身份验证机制,这也使用 全局 provider-sasl-server-factory 按提供程序名称进行过滤。application-sasl-authentication 使用 ApplicationDomain 安全域来验证主体。
已配置(configurable-sasl-server-factory)
这用于根据机制名称过滤 sasl-authentication-factory。在这种情况下,配置 将与 JBOSS-LOCAL-USERDIGEST-MD5 匹配。它还将 wildfly.sasl.local-user.default-user.default-user 设置为 $local
default-permission-mapper

default-permission-mapper 是一个简单的权限映射器,使用 default-permissions 权限集来分配身份访问服务器上任何服务所需的全部权限集。

例如,default-permission-mapper 使用 org.wildfly.extension.batch.jberet.deployment . BatchPermission 权限设置来为批处理作业分配权限。批处理权限为 start、stop、restart、wap 和 read,它与 javax.batch.operations.JobOperator 一致。

default-permission-mapper 还使用 org.wildfly.security.auth.permission.LoginPermission (由 登录权限集指定的) 来分配登录权限。

elytron (mechanism-provider-filtering-sasl-server-factor)
这用于根据提供程序过滤使用 sasl-authentication-factory。在本例中,ely tron 将匹配 WildFlyElytron 提供程序名称。
global(provider-http-server-mechanism-factory)
这是用于在创建 HTTP 身份验证工厂时列出受支持的身份验证机制的 HTTP 服务器工厂机制定义。
global(provider-sasl-server-factory)
这是用于创建 SASL 身份验证工厂的 SASL 服务器工厂定义。
groups-to-roles
groups-to-roles mapper 是一个 simple-role-decoder,它将解码主体的 信息并将其用于 角色 信息。
本地(映射程序)
本地 映射器是一个固定角色映射器,映射到 本地 安全域。这用于将身份验证映射到 本地 安全域。
本地(安全域)
本地 安全域不进行身份验证,并将主体的身份设置为 $local
ManagementDomain
ManagementDomain 安全域使用两个安全域进行身份验证: ManagedRealmgroups-to-roles,并通过 超级用户映射器 local。它还使用 default-permission-mapper 来分配登录权限。
ManagementRealm
ManagementRealm 安全 域是一个属性域,它使用 mgmt-users.properties 验证主体并分配使用 mgmt-roles.properties 的角色。这些文件位于 jboss.server.config.dir 下,默认情况下,该文件映射到 EAP_HOME/standalone/configuration。它们也是与传统安全默认配置使用的相同文件。
management-http-authentication
management-http-authentication http-authentication-factory 可用于通过 HTTP 进行身份验证。它使用 全局 provider-http-server-mechanism-factory 来过滤身份验证机制,并使用 ManagementDomain 验证主体。它接受 DIGEST 身份验证机制,并将它作为 ManagementRealm 公开给应用。
management-sasl-authentication
management-sasl-authentication sasl-authentication-factory 可用于使用 SASL 进行身份验证。它使用 配置的 sasl-server-factory 来过滤身份验证机制,这也使用 全局 provider-sasl-server-factory 按提供程序名称进行过滤。management-sasl-authentication 使用 ManagementDomain 安全域对主体进行身份验证。它还 利用本地 域映射器来映射使用 JBOSS-LOCAL-USER 机制的身份验证,并使用 DIGEST-MD5 向 ManagementRealm 进行身份验证。
super-user-mapper
super-user-mapper 映射程序是一个恒定角色映射器,可将 SuperUser 角色映射到一个主体。

4.1.1. 安全性

为了保证应用安全,JBoss EAP 附带了预配置 application-http-authentication,用于使用 SASL 使用 HTTP 和 application-sasl-authenticationapplication-http-authentication http-authentication-factory 使用 ApplicationDomain,它使用 ApplicationRealmgroups-to-roles 进行身份验证。ApplicationRealm 是一个由 application- users.properties 和 application-roles.properties (用户名、密码和角色信息)支持的 properties-realm。

为了保护管理接口,JBoss EAP 附带了用于 HTTP 的 management-http-authentication 的预配置,以及 SASL 的 management-sasl-authenticationmanagement-http-authentication http-authentication-factory 使用 ManagementDomain,它使用 ManagementRealmgroups-to-roles 进行身份验证。ManagementRealm 是一个由mgmt- users.properties 和 mgmt-roles.properties (用户名、密码和角色信息)支持的 properties-realm。management-sasl-authentication sasl-authentication-factory 使用 ManagementDomain,它使用 local 进行 JBOSS-LOCAL-USER 身份验证,以及 ManagementRealm 进行 DIGEST-MD5 身份验证。

4.1.2. 它如何工作

默认情况下,没有 JBoss EAP 的用户,但本例中添加了以下用户:

表 4.1. 用户

username密码角色Security Realm

Susan

测试123!

 

ManagementRealm

Sarah

测试123!

示例

ApplicationRealm

Frank

测试123!

 

ApplicationRealm

启动时,JBoss EAP 实例加载所有四个身份验证工厂及其关联的安全域、安全域和其他配置的组件。

如果任何人都尝试使用 JBOSS-LOCAL-USER 通过管理 CLI 访问管理界面,换句话说,从与 JBoss EAP 实例相同的主机运行管理 CLI,用户将被定向到 management-sasl-authentication sasl-authentication-factory,它将尝试使用 本地 安全域通过 ManagementDomain 验证用户身份。

如果 Susan 尝试从其他主机使用管理 CLI 访问管理接口,她将使用带有 SASL 的 DIGEST-MD5 身份验证机制。她将被定向到 management-sasl-authentication sasl-authentication-factory,它将尝试使用 Management Realm 安全域通过 Management Domain 验证用户。

如果 Susan 尝试使用基于 Web 的管理控制台访问管理界面,她将使用带有 HTTP 的 DIGEST 身份验证机制。她将被定向到 management-http-authentication http-authentication-factory,它将尝试使用 Management Realm 安全域通过 Management Domain 验证用户。

应用 sampleApp1.war 有两个 HTML 文件,/hello.html/secure/hello.html,并使用 BASIC HTTP 身份验证来保护路径 /secure/*。它使用 Application Realm,它需要 sample 的角色。当用户尝试访问 sampleApp1.war 时,它们将定向到 application-http-authentication http- authentication-factory。它将尝试使用 Application Realm 安全域通过 Application Domain 验证用户。

当 Sarah 请求 /hello.html 时,她可以查看页面而不进行身份验证。当 Sarah 尝试请求 /secure/hello.html 时,系统会提示她输入其用户名和密码。成功登录后,她能够查看 /secure/hello.html。Frank 和 Susan 或任何用户都可以访问 /hello.html,但不能访问 /secure/hello.html。Frank 没有 示例 角色,Susan 不在 ApplicationRealm 安全 域中。

4.2. 使用 SSL/TLS 保护管理接口和应用程序

此情景演示了将 Elytron 用于 SSL/TLS 以及管理接口和应用时如何保护 JBoss EAP。

4.2.1. 安全性

JBoss EAP 提供使用 SSL/TLS 保护管理接口和应用程序的能力。使用 Elytron 时,此配置现已统一,现在您可以选择使用相同的 SSL/TLS 配置保护管理接口和应用程序。通过创建 密钥存储、key-manager 和 server-ssl- context,在 Elytron 中配置 SSL/TLS。通过在 http-interface 上设置 secure-socket-binding,并将 server- ssl- context 分配到管理接口,即可为管理接口启用 SSL/TLS。这可让管理接口将 SSL/TLS 用于 HTTP 流量。通过将 server-ssl-context 分配给 undertow 子系统中的 https- listener,为应用启用 SSL/TLS。有关 SSL/TLS 的更多信息,请参阅高级安全部分

4.2.2. 它如何工作

启动时,JBoss EAP 加载管理接口,作为核心服务的一部分,该服务也启动 http-interface,该接口适用于管理接口的 SSL/TLS。它还会启动 undertow 子系统(针对应用的 SSL/TLS 配置)和 elytron 子系统(通过 server-ssl-context 提供 SSL/TLS 配置)。然后,可以通过启用 SSL/TLS 的安全端口访问管理接口和应用。

4.3. 使用新身份存储保护管理接口和应用程序

此方案演示了 JBoss EAP 中的管理接口和应用如何通过 Elytron 中的新身份存储进行保护。sampleApp2.war 应用已部署到 JBoss EAP,并且配置为使用 basicExampleDomain

4.3.1. 安全性

JBoss EAP 能够通过 ManagementRealm 和 ApplicationRealm 之外的身份存储来保护管理接口和应用程序。借助 Elytron,同一身份存储可用于保护管理接口和应用的安全,但您仍然可以选择为每个用户设置单独的身份存储。身份存储由安全域表示,例如 filesystem-realmjdbc-realmldap-realm。在本示例中,已创建了名为 exampleRealmfilesystem-realm。还创建了一个名为 exampleDomain 的安全域,它使用 exampleRealm 作为身份存储,group -to-roles 角色 映射器对 exampleRealm 提供的组信息进行解码,使用 default-permission-mapper 进行映射权限。

对于 HTTP 身份验证,已创建 http-authentication-factory,名为 exampleHttpAuthFactory。它使用 全局 HTTP 服务器工厂机制和 exampleDomain 进行身份验证。它还有两种机制配置:使用 BASIC 验证方法之一公开为 basicExampleDomain,它使用 DIGEST 身份验证方法作为 摘要ExampleDomain。HTTP 管理接口已配置为使用 exampleHttpAuthFactoryundertow 子系统也配置了一个新的 application-security-domain, 它也使用 exampleHttpAuthFactory。应用 sampleApp2.war 已配置为使用 基本ExampleDomain 和 BASIC 身份验证。

对于 SASL 身份验证,创建了一个名为 exampleSa slAuthFactory 的 sasl -authentication-factory。它使用 配置的 SASL 服务器工厂和 exampleDomain 进行身份验证。它还配置了 DIGEST-MD5 身份验证机制,它作为 摘要MD5ExampleDomain 公开。管理接口的 SASL 配置已设置为使用 exampleSaslAuthFactory

4.3.2. 它如何工作

exampleRealm 中添加了以下用户:

表 4.2. 示例Realm用户

username密码角色

文莱

samplePass

示例

Issac

samplePass

guest

在启动时,JBoss EAP 加载核心服务并启动 undertowelytron 子系统。这可保护管理接口并公开 基本ExampleDomain、secdExampleDomain 和 summary MD5ExampleDomain (部署至 JBoss EAP 的应用)。

加载 sampleApp2.war 后,它会查找 basicExampleDomain 来为其安全 URL 提供身份验证和授权。它有两个 HTML 文件,/hello.html/secure/hello.html,并使用 BASIC 身份验证来保护路径 /secure/*。它要求 sample 角色访问任何安全 URL。

用户进行身份验证时,将使用特定的机制提交其凭据,具体取决于他们如何访问 JBoss EAP。例如,如果用户尝试使用 HTTP 和 DIGEST 身份验证访问管理控制台,他们将使用公开为 摘要ExampleDomain 的 DIGEST 身份验证方法进行身份验证。如果他们尝试使用带有 BASIC 身份验证的 HTTP 访问 sampleApp2.war,则将使用公开为 basicExampleDomain 的 BASIC 身份验证方法进行身份验证。如果他们尝试使用 SASL 通过 DIGEST 身份验证访问管理 CLI,则将使用公开为 摘要MD5ExampleDomain 的 DIGEST-MD5 进行身份验证。HTTP 身份验证机制使用 exampleHttpAuthFactory,SASL 身份验证机制则使用 exampleSaslAuthFactory。使用 exampleDomain 验证工厂处理身份验证和角色映射。

如果文莱或 Issac 试图访问管理界面,系统会提示它们输入用户名和密码。成功登录后,他们分别能够执行管理操作。

当文稿或 Issac 请求 /hello.html 时,他们可以查看该页面而不进行身份验证。当文莱或 Issac 尝试请求 /secure/hello.html 时,系统会提示他们输入用户名和密码。成功登录后,文莱能够查看 /secure/hello.html,因为他拥有 示例 角色,但 Issac 将无法查看 /secure/hello.html,因为他拥有 guest 角色。所有其他用户均可在不登录的情况下访问 /hello.html,但是任何用户都无法访问 /secure/hello.html,因为的订阅和 Issac 是 exampleRealm 中唯一的用户。

4.4. 使用 RBAC 保护管理接口

此情景演示了 JBoss EAP 管理接口如何通过 elytron 子系统中的 RBAC 和身份存储来保护。

4.4.1. 安全性

JBoss EAP 提供在管理接口上使用 RBAC 的功能。RBAC 部分介绍了 RBAC 背后的概念。本例使用名为 exampleRealm 的安全域。安全配置的其余部分(包括角色解码器、安全域和身份验证工厂)与通过新 Identity Store 部分保护管理接口和应用部分中相同。通过设置管理接口的 provider 属性 to rbac 并使用所需的用户和角色更新 exampleRealm 来启用 RBAC。

4.4.2. 它如何工作

在这种情况下,在现有安全域中添加了以下用户:

表 4.3. 示例Realm用户

username密码

Suzy

测试123!

Tim

测试123!

Emily

测试123!

Zach

测试123!

Natalie

测试123!

根据组成员资格,用户也映射到以下 RBAC 角色:

表 4.4. RBAC 角色

usernameRBAC 角色

Suzy

超级用户

Tim

Administrator

Emily

Maintainer

Zach

deployer

Natalie

Monitor

在启动时,JBoss EAP 加载核心服务和 elytron 子系统,它们将加载安全配置和 RBAC 配置。如果没有启用 RBAC,example Realm 中的任何用户 都将被视为 SuperUser,且具有无限访问权限。由于启用了 RBAC,因此每个用户现在都会根据他们的角色进行限制。Suzy、Tim、Emily、Zach 和 Natalie 具有不同的角色,如上表中所示。例如,只有 Suzy 和 Tim 才能读取和修改访问控制信息。Suzy、Tim 和 Emily 可以修改运行时状态和其他持久配置信息。Zach 还可以修改运行时状态和其他持久配置信息,但仅与应用资源相关。Suzy、Tim、Emily、Zach 和 Natalie 可以读取配置和状态信息,但 Natalie 无法更新任何内容。有关每个角色以及 JBoss EAP 如何处理 RBAC 的更多详细信息,请参阅基于角色的访问控制和将 RBAC 添加到管理接口部分

4.5. 使用 Kerberos 为 Web 应用提供 SSO

此情景演示了如何将 Kerberos 与 JBoss EAP 搭配使用,以便为 Web 应用提供 SSO。JBoss EAP 实例已经创建,即 EAP1,它作为单机服务器运行。已将 sampleAppAsampleAppB 这两个 Web 应用部署到 EAP1。Web 应用和 EAP1 都已配置为通过 Kerberos 使用基于桌面的 SSO 进行身份验证。

4.5.1. 安全性

JBoss EAP 使用 SPNEGO 身份验证方法通过 Kerberos 提供身份验证。有关 Kerberos 和 SPNEGO 细节的更多信息,请参阅第三方 SSO 实施部分。为了使 JBoss EAP 和部署的 Web 应用能够使用 Kerberos 进行身份验证,请创建一个 kerberos-security-factory 来连接 Kerberos 服务器。同时也创建一个安全域、角色映射器和安全域,以便将角色分配给来自 Kerberos 服务器的用户。创建一个 http-authentication-factory,它使用 kerberos-security-factory 并使用安全域进行身份验证和角色分配。身份验证机制使用 SPNEGO 身份验证机制作为 exampleSpnegoDomain 公开。undertow 子系统也配置为使用 http-authentication-factory 进行身份验证。

sampleAppAsampleAppB 都配置为使用 exampleSpnegoDomain 执行身份验证并获取用户的角色以进行授权。当安全令牌无法从操作系统传递到浏览器 ,这两个应用也可以将 FORM 身份验证配置为回退身份验证机制。如果 FORM 身份验证 配置为回退,则必须配置额外的身份验证机制以及支持的安全域。此身份验证机制独立于 Kerberos 和 SPNEGO,仅需支持 FORM 身份验证。在本例中,已经为 FORM 身份验证 配置了额外的机制和支持安全域,并作为 exampleFormDomain 公开。每个应用都配置为使用 exampleFormDomain,并提供 FORM 身份验证 作为回退。每个应用程序也被配置为保护路径 /secure/*,并提供自己的角色列表来处理授权。

4.5.2. 它如何工作

在 Kerberos 服务器中创建了以下用户:

表 4.5. Kerberos 用户

username密码

Sande

samplePass

Andrea

samplePass

Betty

samplePass

Chuck

samplePass

以下角色使用安全域映射到用户:

表 4.6. 用户角色

username角色

Sande

all

Andrea

A

Betty

B

Chuck

 

每个应用程序中也配置了以下角色:

表 4.7. 应用程序角色

应用程序/SP允许的角色

sampleAppA

所有,A

sampleAppB

所有,B

在启动时,EAP1 加载核心服务,后跟 elytron 和其他子系统。kerberos-security-factory 建立与 Kerberos 服务器的连接。sampleAppAsampleAppB 都已部署,并连接到 exampleSpnegoDomainexampleFormDomain 进行身份验证。

Sande 已登录到使用 Kerberos 保护的计算机。她打开浏览器并尝试访问 sampleAppA/secure/hello.html。由于这一点是安全的,因此需要进行身份验证。EAP1 指示浏览器向 Kerberos 服务器发送密钥请求,特别是在其计算机上配置的 Kerberos 密钥分发中心。浏览器获取密钥后,它将被发送到 sampleAppAsampleAppA 使用 exampleSpnegoDomain 将 ticket 发送到 JBoss EAP,其中将它解包并且身份验证与 kerberos-security-factory 中配置的 Kerberos 服务器一同执行。票据通过身份验证后,Sande 的角色将传回 sampleAppA 以执行授权。由于 Sande 具有 all 角色,因此她将能够访问 sampleAppA/secure/hello.html。如果 Sande 尝试访问 sampleAppB/secure/hello.html,则会出现同一个进程。由于她拥有 所有 角色,她将获得访问权限。Andrea 和 Betty 将遵循相同的流程,但 Andrea 只能访问 sampleAppA/secure/hello.html,并且没有 sampleAppB/secure/hello.html。Betty 的情况相反,它有权访问 sampleAppB/secure/hello.html,并且没有 sampleAppA/secure/hello.html。Chuck 会将身份验证传递给 sampleAppA/secure/hello.htmlsampleAppB/secure/hello.html,但不会获得对其的访问权限,因为他没有任何角色。

如果 Sande 试图从没有 Kerberos 保护的计算机访问 sampleAppA/secure/hello.html,例如,与 Office 网络连接的个人笔记本电脑,她会作为回退定向到 FORM 登录 页面。然后,她的凭据将使用回退身份验证机制进行身份验证,进程将继续获得授权。

第 5 章 旧版核心管理和安全子系统示例方案

理解 JBoss EAP 安全性及其组件如何协同工作的一种方法是回顾真实情况。以下小节涵盖了涉及各种 JBoss EAP 安全组件和配置选项的几种通用但现实情况。它们侧重于如何保护应用程序或一组应用程序,以及如何保护管理接口。

5.1. Red Hat JBoss Enterprise Application Platform Out the Box

此情景演示了在初始安装后未进行任何配置更改时,JBoss EAP 和示例应用是如何安全的。应用 sampleApp1.war 已部署并配置为使用基于容器的安全性。

scenario1

5.1.1. 来自 Box 的核心管理身份验证

5.1.1.1. 安全性

Core Management Authentication 默认提供两个预配置的安全域: ManagementRealmApplicationRealm。这些域使用属性文件来存储用户名、密码和角色。ManagementRealm (用于存储身份验证信息和管理 API)也为在与 JBoss EAP 实例相同的主机上使用 CLI 的用户定义和启用本地身份验证。ApplicationRealm 已预先配置为存储身份验证和授权信息,但用于管理 API 之外的其他应用。另外,AppRealm 预配置了启用本地身份验证,但并不常用。

5.1.1.2. 它如何工作

在这种情况下,以下用户已添加到 JBoss EAP 的默认安装中:

表 5.1. 用户

username密码角色Security Realm

Susan

测试123!

 

ManagementRealm

Sarah

测试123!

示例

ApplicationRealm

Frank

测试123!

 

ApplicationRealm

启动时,JBoss EAP 实例加载 ManagementRealmApplicationRealm 安全 域。

如果 Susan 尝试访问 HTTP 或 CLI 任一管理接口,则必须进行身份验证。她的用户名、密码和角色必须与 ManagementRealm 安全 域中的条目匹配。默认情况下,不需要角色即可访问管理 API。Sarah 和 Frank 无法访问管理 API,因为它们不在 ManagementRealm 安全领域。

5.1.2. 安全子系统从 Box 中移出

5.1.2.1. 安全性

security 子系统预配置了四个安全域:other jboss-web-policyjboss-ejb-policyjaspitest其他 安全域通过委派到登录模块中指定的域来执行身份验证和授权,默认情况下,该域使用 ApplicationRealm

有关默认安全域和默认安全域的其他信息,请参阅 Security Realms and Security Domains 部分。

5.1.2.2. 它如何工作

应用 sampleApp1.war 有两个 HTML 文件: /hello.html/secure/hello.html,并使用基本的 HTTP 身份验证来保护路径 /secure/*。它使用 其他 安全域,需要 sample 的角色。因为 其他 安全域会延迟到 ApplicationRealm 获取其身份验证和授权信息,因此请参考上 一节中Users 表中的用户。

当 Sarah 请求 /hello.html 时,她可以查看页面而不进行身份验证。当 Sarah 尝试请求 /secure/hello.html 时,系统会提示她输入其用户名和密码。成功登录后,她能够查看 /secure/hello.html。Frank 和 Susan 或任何用户都可以访问 /hello.html,但不能访问 /secure/hello.html。Frank 没有 示例 角色,Susan 不在 ApplicationRealm 安全 域中。

5.2. 带有 HTTPS 和 RBAC 的红帽 JBoss 企业应用平台添加到管理接口中

此情景演示了在为管理接口启用 HTTPS 并且将 RBAC 添加到 ManagementRealm 安全域时,JBoss EAP 是如何安全的。

scenario2

5.2.1. 安全性

JBoss EAP 支持将 HTTPS 与管理界面(包括管理控制台)搭配使用。若要启用 HTTPS,可以配置 secure-interface 元素,添加 secure -port 到管理接口的 http-interface 部分,然后使用所需的设置配置现有或新的安全域,如 server-identity、协议、密钥存储、别名等。这可让管理接口对所有 HTTP 流量使用 SSL/TLS。有关 HTTPS 并保护管理接口的更多背景信息,请参阅高级安全部分

JBoss EAP 还提供使用几种不同的身份验证方案在管理接口上启用 RBAC 的功能。本例使用用户名和密码身份验证以及 ManagementRealm 中使用的现有属性文件。通过设置管理接口的 provider 属性 to rbac 并使用所需的用户和角色更新 ManagementRealm 来启用 RBAC。

5.2.2. 它如何工作

在这种情况下,在现有安全域中添加了以下用户:

表 5.2. 管理用户

username密码Security Realm

Suzy

测试123!

ManagementRealm

Tim

测试123!

ManagementRealm

Emily

测试123!

ManagementRealm

Zach

测试123!

ManagementRealm

Natalie

测试123!

ManagementRealm

根据组成员资格,用户也映射到以下 RBAC 角色:

表 5.3. RBAC 角色

usernameRBAC 角色

Suzy

超级用户

Tim

Administrator

Emily

Maintainer

Zach

deployer

Natalie

Monitor

在启动时,JBoss EAP 会加载将 RBAC 配置和管理接口作为核心服务的一部分的 ManagementRealm,该服务也会启动 http-interface( 为 HTTPS 配置)用于管理接口。现在,用户通过 HTTPS 访问管理接口,RBAC 也被启用和配置。如果没有启用 RBAC,ManagementRealm 安全 域中的任何用户都将被视为 SuperUser,且具有无限访问权限。由于启用了 RBAC,因此每个用户现在都会根据他们的角色进行限制。Suzy、Tim、Emily、Zach 和 Natalie 具有不同的角色,如上表中所示。例如,只有 Suzy 和 Tim 才能读取和修改访问控制信息。Suzy、Tim 和 Emily 可以修改运行时状态和其他持久配置信息。Zach 还可以修改运行时状态和其他持久配置信息,但仅与应用资源相关。Suzy、Tim、Emily、Zach 和 Natalie 可以读取配置和状态信息,但 Natalie 无法更新任何内容。有关每个角色以及 JBoss EAP 如何处理 RBAC 的更多详细信息,请参阅基于角色的访问控制和将 RBAC 添加到管理接口部分

5.3. 带有更新的安全子系统(包括 HTTPS)的 Red Hat JBoss Enterprise Application Platform

此情景演示了在添加新安全域和启用 HTTPS 时如何保护 JBoss EAP 上运行的示例应用。部署了 sampleApp2.war 应用,它配置为使用基于容器的安全性、样本域 和 HTTPS。

scenario3

5.3.1. 安全性

JBoss EAP 支持将 HTTPS 用于应用,这些应用使用 undertow 子系统来处理。HTTPS 的新连接器将添加到 undertow 子系统中,并且配置了所需的设置,如协议、端口和密钥存储等。保存配置后,Web 应用程序就可以开始接受配置的端口上的 HTTPS 流量。添加了一个名为 sample-domain 的新安全域,它使用 IdentityLoginModule 进行身份验证。sampleApp2.war 已配置为使用 sample-domain 来验证用户身份。

5.3.2. 它如何工作

已创建安全域 sample-domain,并配置为使用 IdentityLoginModule。登录模块中配置了以下凭证:

表 5.4. 示例域用户

username密码角色

文莱

samplePass

示例

在启动时,JBoss EAP 加载核心服务并启动 undertowsecurity 子系统,这些子系统分别管理所有 Web 应用和 sample-domain 的 HTTPS 连接。sampleApp2.war 已加载,并查找 sample-domain,以便为其安全 URL 提供身份验证和授权。sampleApp2.war 有两个 HTML 文件 /hello.html/secure/hello.html,并使用基本的 HTTP 身份验证来保护路径 /secure/*。它使用 sample-domain 安全域,需要 sample 的角色。

当文稿请求 /hello.html 时,他能够查看该页面而不进行身份验证。当葡萄牙尝试请求 /secure/hello.html 时,会提示他输入其用户名和密码。成功登录后,他能够查看 /secure/hello.html。所有其他用户均可在不登录的情况下访问 /hello.html,但是任何用户都无法访问 /secure/hello.html,因为文莱是 sample-domain 中的唯一用户。这也适用于通过 HTTPS 处理的所有流量。

5.4. 红帽 JBoss 企业应用平台上 Web 应用程序的 SSO

此情景演示了 Web 应用如何利用 JBoss EAP 上的集群和非集群 SSO。创建四个 JBoss EAP 实例: EAP1EAP2EAP3EAP4EAP1EAP2 作为单机服务器运行,EAP 3EAP4 则作为双节点集群运行。已将 sampleAppAsampleAppB 这两个 Web 应用部署到四个 JBoss EAP 实例中的每一个。

scenario4

5.4.1. 安全性

JBoss EAP 通过结合使用 securityundertowinfinispan 子系统的组合,支持集群和非集群 SSO 使用 Web 应用。security 子系统提供一个安全域来执行身份验证和授权,而 infinispanundertow 子系统则帮助在 JBoss EAP 实例或 JBoss EAP 集群上的所有 Web 应用之间缓存和分发 SSO 信息。所有四个 EAP 实例都有一个安全域( sso-domain),配置为使用 IdentityLoginModulesampleAppAsampleAppB 已配置为使用 sso-domain 安全域来保护路径 /secure/*,并要求 示例 的角色来访问它。在 sso-domain 登录模块中配置了以下凭证:

表 5.5. SSO-domain 用户

username密码角色

jane

samplePass

示例

所有四个 JBoss EAP 实例也已配置为使用 standalone-full-ha 或 full-ha 配置文件 启动,它添加了 infinispan 子系统和在这种情况下启用 SSO 所需的其他功能。还添加了 Web cache-container 和 SSO replication-cache,并且 undertow 子系统已配置为同时使用它们。EAP1EAP2 已将 undertow 子系统配置为非集群 SSO,而包含 EAP3EAP4 的集群已配置为使用集群 SSO。

应用程序群集与.集群的 SSO

集群 Web 应用和集群的 SSO 之间有区别。集群 Web 应用是在集群节点上分布的,以分散托管该应用的负载。在标记为 distributable 的群集应用中,对现有会话的所有新会话和更改都将复制到群集的其他成员。集群 SSO 允许复制安全上下文和身份信息,无论应用本身是否集群。尽管这些技术可以一起使用,但它们是互斥的,可以独立使用。

5.4.2. 它如何工作

在启动时,JBoss EAP 加载核心服务并启动管理 以及 SSO 信息的相关缓存 的安全性undertowinfinispan 子系统。sampleAppA.warsampleAppB.war 加载到所有四个 JBoss EAP 实例上,各自查找 sso-domain 来提供身份验证和授权。

如果 Jane 尝试访问 EAP1/sampleAppA/secure/hello.html,将要求她进行身份验证。在提供了正确的信息后,她将被允许查看 EAP1/sampleAppA/secure/hello.html。Jane 的会话将添加到 undertowinfinispan 子系统使用的 SSO 缓存中。如果她试图访问 EAP1/sampleAppB/secure/hello.html,则不会要求她重新进行身份验证。在 EAP1 上运行的 sampleAppB 将利用 undertow 子系统缓存和 infinispan 子系统查找她的会话,并授予她的访问权限,因为她已经过身份验证。如果 Jane 尝试访问 EAP2/sampleAppA/secure/hello.htmlEAP2/sampleAppB/secure/hello.html,她将被要求再次进行身份验证,因为 EAP1EAP2 不共享缓存。

如果 Jane 尝试访问 EAP3/sampleAppA/secure/hello.html,她将被要求进行身份验证,并且她的会话将存储在 SSO 缓存中。这些缓存存储在整个集群中;因此,如果 Jane 尝试登录 EAP3/sampleAppB/secure/hello.htmlEAP4/sampleAppA/secure/hello.htmlEAP4/sampleAppB/secure/hello.html,她就不必重新进行身份验证。如果 EAP3EAP4 重新启动,Jane 的 SSO 信息将保留在缓存中,因为其他 JBoss EAP 实例和群集仍在运行,从而保留了缓存。同样,如果 Jane 的会话无效,它将在整个缓存中拔出,并且无论她尝试在群集中访问哪个应用或服务器,系统都会要求她重新进行身份验证。

5.5. 使用基于浏览器和 SAML 的 SSO,多个红帽 JBoss 企业应用平台实例和多个应用程序

此情景演示了如何保护多个 JBoss EAP 实例,以及添加基于浏览器的 SSO。配置了三个独立的非集群 JBoss EAP 实例:EAP 1EAP2EAP3。三个示例应用: sampleAppA.warsampleAppB.warsampleAppC.war 已配置为使用基于浏览器的 SSO 进行身份验证。

scenario5

5.5.1. 安全性

JBoss EAP 支持通过 SAML 通过 Web 应用程序执行基于浏览器的 SSO,以及托管身份提供程序。若要托管身份提供程序,必须定义身份验证机制来配置这种情况下名为 idp-domain 的安全域。在这种情况下,idp-domain 被配置为使用 DatabaseLoginModule 作为身份验证机制。IDP 应用(如 IDP.war )已部署到 JBoss EAP 实例,在本例中 为 EAP-IDP,并且配置为使用 idp-domain 作为其身份存储。IDP.war 使用身份存储与应用的功能相结合,以验证用户身份和角色信息,以及发行包含用户身份和角色信息的 SAML 令牌。另外三个 JBoss EAP 实例: EAP1EAP2EAP3,各自托管一个不同的应用,分别充当单独的 SP、sampleAppA.warsampleAppB.warsampleAppC。每个 JBoss EAP 实例都有一个安全域( sso-domain),配置为使用 SAML2LoginModule 作为身份验证机制。每一应用包含支持 SSO 的功能,使用 IDP.war 作为身份提供程序,并使用 HTTP/POST 绑定进行身份验证。每个应用程序也被配置为使用so -domain 来保护路径 /secure/*,并提供自己的角色列表来处理授权。

5.5.2. 它如何工作

在这种情况下,以下用户被添加到 idp-domain 安全域中 DatabaseLoginModule 使用的数据库中:

表 5.6. IDP-domain 用户

username密码角色

eric

samplePass

all

amar

samplePass

AB

brian

samplePass

C

alan

samplePass

 

EAP-IDP 启动时,管理接口将启动,后跟子系统和部署的应用,包括 security 子系统(包括 idp-domainIDP.war )。IDP-domain 连接到数据库,并加载 DatabaseLoginModule 登录模块中配置的用户名、密码和角色。为了防止敏感信息以纯文本形式存储在 DatabaseLoginModule 登录模块的配置中,密码哈希被配置为模糊某些字段,例如数据库的密码。IDP.war 使用 idp-domain 进行身份验证和授权。还配置 IDP.war,使用 jboss-web.xml、web.xmlpicketlink.xmljboss-deployment-structure.xml,向经过身份验证的用户发布 SAML 令牌,并为用户提供简单的登录形式以进行身份验证。这允许它充当 IDP。

EAP1、EAP2EAP3 启动时,管理接口启动,后跟子系统和部署的应用,其中包括每个实例 上的 security 子系统,以及 sampleAppA.warsampleAppB.warsampleAppC.warSSO-domain 已配置为使用 SAML2LoginModule 登录模块,但依赖于应用来提供正确的 SAML 令牌。这意味着,任何使用 sso-domain 的应用程序都必须正确连接到 IDP 以获取 SAML 令牌。在本例中,Sample AppA、SampleAppBsampleAppC 各自通过 jboss-web.xml、web.xmlpicketlink.xmljboss-deployment-structure.xml 配置,以使用 IDP 的登录表单从 IDP、IDP.war 获取 SAML 令牌。

每个应用程序也配置有自己的一组允许的角色:

表 5.7. 应用程序/SP 角色

应用程序/SP允许的角色

sampleAppA

所有,AB

sampleAppB

所有,AB

sampleAppC

所有,C

当未经身份验证的用户尝试访问由 sso-domain(即 任何应用程序的 /secure/* )保护的 URL 时,该用户会被重定向到 IDP.war 的登录页面。然后,用户使用表单进行身份验证,并签发包含其身份和角色信息的 SAML 令牌。用户重定向到原始 URL,其 SAML 令牌呈现给应用 SP。应用确保 SAML 令牌有效,然后根据 SAML 令牌提供的角色和应用中配置的角色授权用户。签发 SAML 令牌后,他们使用该令牌在 SSO 使用同一 IDP 保护的其他应用上进行身份验证和授权。SAML 令牌过期或无效后,用户需要从 IDP 获取新的 SAML 令牌。

在本例中,如果 Eric accesses EAP1/sampleAppA/secure/hello.html,他会被重定向到 EAP-IDP/IDP/login.html 进行登录。成功登录后,他将签发包含其用户信息和角色的 SAML 令牌, 重定向到 EAP1/sampleAppA/secure/hello.html。他的 SAML 令牌将提供给 sampleAppA,以检查并根据他的角色授权他。因为 sampleAppA 允许所有 角色和 AB 访问 /secure/*,并且 Eric 拥有 全部 角色,因此他可以访问 EAP1/sampleAppA/secure/hello.html

如果 Eric 尝试访问 EAP2/sampleAppB/secure/hello.html,因为尚未对该 SP 进行身份验证,他会通过身份验证请求重定向到 IDP.war。由于 Eric 已针对 IDP 进行了身份验证,因此他已被 IDP.war 重定向到 EAP2/sampleAppB/secure/hello.html,且具有该 SP 的新 SAML 令牌,无需重新身份验证。sampleAppB 检查其新的 SAML 令牌,并根据他的角色授权他。因为 sampleAppB 允许所有 角色和 AB 访问 /secure/*,并且 Eric 拥有 全部 角色,因此他可以访问 EAP2/sampleAppB/secure/hello.html。如果 Eric 试图访问 EAP3/sampleAppC/secure/hello.html,则同样适用。

如果 Eric 返回 EAP1/sampleAppA/secure/hello.htmlEAP2/sampleAppB/secure/*EAP3/sampleAppC/secure/* 下的任何 URL,则在 SAML 令牌通过全局注销无效后,他会被重定向到 EAP-IDP/IDP/login.html 以再次进行身份验证并发布新的 SAML 令牌。

如果 Amar 试图访问 EAP1/sampleAppA/secure/hello.htmlEAP2/sampleAppB/secure/hello.html,他将被定向到与 Eric 相同的流。如果 Amar 试图访问 EAP3/sampleAppC/secure/hello.html,仍然需要他拥有或获取 SAML 令牌,但将被限制为查看 EAP3/sampleAppC/secure/hello.html,因为角色 AB 仅允许他访问 EAP1/sampleAppA/secure/*EAP2/sampleAppB/secure/*。Brian 处于类似情况,但只能访问 EAP3/sampleAppC/secure/*。如果 Alan 试图访问服务提供商的安全区域,则仍然需要他拥有或获取 SAML 令牌,但会因为没有角色而被限制查看任何内容。每个 SP 都有一个不安全的区域,任何经授权与否的用户都可以查看,而无需获取 SAML 令牌。

5.6. 将 LDAP 与 ManagementRealm 搭配使用

此情景显示 ManagementRealm 使用 LDAP 来保护管理接口。JBoss EAP 实例已经创建,即 EAP1,它作为单机服务器运行。EAP1 上的 ManagementRealm 也进行了更新,以使用 LDAP 作为身份验证和授权机制。

scenario6

5.6.1. 安全性

JBoss EAP 支持使用 LDAP 和 Kerberos 在安全域中进行身份验证。这可以通过更新现有 ManagementRealm 以使用 ldap 作为身份验证类型并创建到 LDAP 服务器的出站连接来实现。这会将身份验证机制从 摘要 更改为 BASIC/ Plain,并将默认通过网络明确传输用户名和密码。

5.6.2. 它如何工作

在 LDAP 目录中添加了以下用户:

表 5.8. 管理用户

username密码角色

Adam

samplePass

超级用户

Sam

samplePass

 

在启动时,EAP1 加载核心服务,包括 ManagementRealm 和管理接口。ManagementRealm 连接到 LDAP 目录服务器,并根据需要为管理接口提供身份验证。

如果 Adam 尝试访问管理接口,则必须他进行身份验证。他的凭据将传递到 ManagementRealm 安全 域,该域将使用 LDAP 目录服务器进行身份验证。由于 EAP1 使用默认的简单访问控制,在通过身份验证后,Adam 的角色不会被检查,并将被授予访问权限。如果 Sam 尝试访问管理界面,则会出现相同的过程。

如果在 Adam 验证后启用了 RBAC,其角色将传回到管理界面以进行身份验证。由于 Adam 具有 SuperUser 角色,因此它将被授予管理界面的访问权限。如果 Sam 试图访问启用了 RBAC 的管理接口,他将通过 LDAP 进行身份验证,但会被拒绝访问,因为他没有适当的角色。

5.7. 使用 Kerberos 为 Web 应用程序提供 SSO

此情景演示了如何将 Kerberos 与 JBoss EAP 搭配使用,以便为 Web 应用提供 SSO。JBoss EAP 实例已经创建,即 EAP1,它作为单机服务器运行。已将 sampleAppAsampleAppB 这两个 Web 应用部署到 EAP1。Web 应用和 EAP1 都已配置为通过 Kerberos 使用基于桌面的 SSO 进行身份验证。

scenario7

5.7.1. 安全性

JBoss EAP 支持通过 SPNEGO 和 JBoss Negotiation 在 Web 应用程序中使用 Kerberos 作为 SSO。有关 Kerberos 和 SPNEGO 细节的更多信息,请参阅第三方 SSO 实施部分。要让 JBoss EAP 和部署的 Web 应用能够使用 Kerberos 进行身份验证,必须创建两个安全域:第一个安全域 host-domain 配置有 kerberos 登录模块以连接到 Kerberos 服务器。这使得 JBoss EAP 能够在容器级别进行身份验证。第二个安全域 spnego-domain 使用两个登录模块创建。个使用 spnego 登录模块连接到 host-domain 以 验证用户的身份。第二个模块可以使用任何其他登录模块加载用于授权决策的角色信息,例如,UsersRoles 使用属性文件将用户映射到角色。

这两个登录模块也利用 password-stacking 将 授权模块中的用户和角色与身份验证登录模块中的用户映射。EAP1 同时配置 host-domainspnego-domain。通过 web.xmljboss-web.xml 配置应用,以使用 spnego-domain 进行身份验证并获取用户的角色进行身份验证。如果无法将安全令牌从操作系统传递到浏览器,则应用也可以将 FORM 身份验证配置为回退身份验证机制。如果 FORM 身份验证配置为回退,则必须配置额外的安全域来支持它。此安全域独立于 Kerberos 和 SPNEGO,并且仅支持 FORM 身份验证,即用户名和密码验证以及角色。每个应用都配置为使用 spnego-domain,并提供 FORM 身份验证作为回退。每个应用程序也被配置为保护路径 /secure/*,并提供自己的角色列表来处理授权。

5.7.1.1. 它如何工作

在 Kerberos 服务器中创建了以下用户:

表 5.9. Kerberos 用户

username密码

Brent

samplePass

Andy

samplePass

Bill

samplePass

ron

samplePass

以下角色通过一个额外的模块映射到用户,该模块通过将 password-stacking 选项设置为 使用FirstPass 来串联:

表 5.10. 用户角色

username角色

Brent

all

Andy

A

Bill

B

ron

 

每个应用程序中也配置了以下角色:

表 5.11. 应用程序角色

应用程序/SP允许的角色

sampleAppA

所有,A

sampleAppB

所有,B

在启动时,EAP1 加载核心服务,后跟 security 和其他子系统。host-domain 建立与 Kerberos 服务器的连接,并且 spnego-domain 连接到 host-domainsampleAppAsampleAppB 已部署并连接到 spnego-domain 进行身份验证。

Brent 已登录到使用 Kerberos 保护的计算机。他打开浏览器并尝试访问 sampleAppA/secure/hello.html。由于这一点是安全的,因此需要进行身份验证。EAP1 指示浏览器向 Kerberos 服务器发送密钥请求,特别是在其计算机上配置的 Kerberos 密钥分发中心。浏览器获取密钥后,它将被发送到 simpleAppAsimpleAppA 将票据发送到 spnego-domain,该票据被解包,并且身份验证由 host-domain 与配置的 Kerberos 服务器结合使用。票据通过身份验证后,Braent 的角色将传回 simpleAppA 以执行授权。由于 Brent 具有 all 角色,因此他能够访问 sampleAppA/secure/hello.html。如果 Brent 尝试访问 sampleAppB/secure/hello.html,则会出现同一个进程。由于他拥有 所有 角色,因此他将获得访问权限。Andy 和 Bill 将遵循同样的过程,但 Andy 只能访问 sampleAppA/secure/hello.html,并且没有 sampleAppB/secure/hello.html。Bill 将是相反的,它有权访问 sampleAppB/secure/hello.html 且没有 sampleAppA/secure/hello.html。Ron 会将身份验证传递给 sampleAppA/secure/hello.htmlsampleAppB/secure/hello.html,但不会获得对它的访问权限,因为他没有角色。

如果 Andy 试图从未由 Kerberos 保护的计算机访问 sampleAppA/secure/hello.html,例如连接到 Office 网络的个人笔记本电脑,他将被定向到 FORM 登录页面,作为回退登录机制。然后,他的凭据将通过回退安全域进行身份验证,进程将继续获得授权。





在 2022-07-02 18:10:02 +1000 上修订