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

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

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

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

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

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

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

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

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

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

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

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

图 2.1. Elytron 身份验证流程

预域映射

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

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

图 2.2. 预域映射

域名称映射

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

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

图 2.3. 域名称映射

安装后映射

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

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

图 2.4. 安装后映射

最终主要转换

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

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

图 2.5. 最终主要转换

获取 Realm 身份

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

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

HttpAuthenticationFactory 参考以下内容：

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

SaslAuthenticationFactory 参考以下内容：

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

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

工厂

主体转换器

主体 Decoders

realm Mappers

realm

权限映射器

角色解码器

角色映射器

SSL 组件

其他

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

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

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

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

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

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

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

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

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

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

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

Elytron 和 PicketBox 安全域之间的比较

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

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

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

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

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

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

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

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

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

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

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

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

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

为了保护管理接口，JBoss EAP 附带了用于 HTTP 的 management-http-authentication 的预配置，以及 SASL 的 management-sasl-authentication。management-http-authentication http-authentication-factory 使用 ManagementDomain，它使用 ManagementRealm 和 groups-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 身份验证。

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

启动时，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 安全 域中。

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 的更多信息，请参阅高级安全部分。

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

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

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

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

在 exampleRealm 中添加了以下用户：

在启动时，JBoss EAP 加载核心服务并启动 undertow 和 elytron 子系统。这可保护管理接口并公开 基本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 中唯一的用户。

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

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

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

在启动时，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 添加到管理接口部分。

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 进行身份验证。

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

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

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

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

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

Sande 已登录到使用 Kerberos 保护的计算机。她打开浏览器并尝试访问 sampleAppA/secure/hello.html。由于这一点是安全的，因此需要进行身份验证。EAP1 指示浏览器向 Kerberos 服务器发送密钥请求，特别是在其计算机上配置的 Kerberos 密钥分发中心。浏览器获取密钥后，它将被发送到 sampleAppA。sampleAppA 使用 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.html 或 sampleAppB/secure/hello.html，但不会获得对其的访问权限，因为他没有任何角色。

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

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。

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

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

在启动时，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 添加到管理接口部分。

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

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

在启动时，JBoss EAP 加载核心服务并启动 undertow 和 security 子系统，这些子系统分别管理所有 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 处理的所有流量。

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

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

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

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

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

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

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

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

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

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

当未经身份验证的用户尝试访问由 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.html 或 EAP2/sampleAppB/secure/* 或 EAP3/sampleAppC/secure/* 下的任何 URL，则在 SAML 令牌通过全局注销无效后，他会被重定向到 EAP-IDP/IDP/login.html 以再次进行身份验证并发布新的 SAML 令牌。

如果 Amar 试图访问 EAP1/sampleAppA/secure/hello.html 或 EAP2/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 令牌。

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

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

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

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

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

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-domain 和 spnego-domain。通过 web.xml 和 jboss-web.xml 配置应用，以使用 spnego-domain 进行身份验证并获取用户的角色进行身份验证。如果无法将安全令牌从操作系统传递到浏览器，则应用也可以将 FORM 身份验证配置为回退身份验证机制。如果 FORM 身份验证配置为回退，则必须配置额外的安全域来支持它。此安全域独立于 Kerberos 和 SPNEGO，并且仅支持 FORM 身份验证，即用户名和密码验证以及角色。每个应用都配置为使用 spnego-domain，并提供 FORM 身份验证作为回退。每个应用程序也被配置为保护路径 /secure/*，并提供自己的角色列表来处理授权。