1.5. Kerberos 如何为 JBoss EAP 提供 SSO?


Kerberos 通过向客户端和服务器发出 KDC 票据,提供基于桌面的 SSO。JBoss EAP 可以通过在自己的身份验证和授权流程中使用相同的票据,集成此现有流程。在尝试了解 JBoss EAP 如何重复使用这些票据之前,最好先更加详细地了解发出这些票据的方式,以及不使用 JBoss EAP 的 SSO 与 Kerberos 配合使用的身份验证和授权。

为提供身份验证和授权,Kerberos 依靠第三方 KDC 为访问服务器的客户端提供身份验证和授权决策。这些决定分为三个步骤:

  1. 身份验证交换.

    当主体首先访问网络或尝试访问受保护的服务时,无需票据授予票据(TGT)时,他们将面临通过其凭证对身份验证服务(AS)进行身份验证的挑战。AS 根据配置的身份存储验证用户提供的凭据,在成功通过身份验证后,主体将发出 TGT,由客户端缓存。TGT 还包含一些会话信息,从而保证将来客户端和 KDC 之间的通信安全。

  2. 票据授予或授权交换.

    委托人获得 TGT 后,即可尝试访问受保护的服务或资源。主体发送请求到向问题单授予服务(TGS),传递由 KDC 发出的 TGT,并为特定目的地请求服务票据(ST)。TGS 检查由主体提供的 TGT,并验证它们是否具有访问请求的资源的适当权限。如果成功,TGS 会发出 ST 供主体访问该特定目的地。TGS 还为客户端和目标服务器创建会话信息,以允许两者之间的安全通信。此会话信息是单独加密的,这样客户端和服务器只能使用 KDC 单独提供的长期密钥来解密其自身的会话信息,与之前的事务。TGS 随后通过 ST 响应客户端,该 ST 包含客户端和服务器的会话信息。

  3. 访问服务器.

    现在主体有安全服务 ST 以及与该服务器进行安全通信的机制,客户端现在可以建立连接并尝试访问受保护的资源。客户端首先将 ST 传递到目标服务器。此 ST 包含从该目的地从 TGS 收到的会话信息的服务器组件。服务器尝试使用来自 KDC 的长期密钥解密客户端传递给它的会话信息。如果成功,客户端已成功通过服务器的身份验证,并且该服务器也被视为对客户端进行身份验证。此时,在客户端和服务器之间建立了信任并可以继续进行通信。

注意

尽管未经授权的主体实际上无法使用 TGT,但只有在他们首次与 AS 成功验证后,才会颁发 TGT。这不仅可确保只签发了经适当授权的主体,而且还会降低未经授权的第三方获取 TGT 的能力,以试图破坏或利用它们,例如使用脱机词典或暴力攻击。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部