3.4 用户认证要求
Jakarta EE 产品提供商必须满足以下与用户认证相关的要求。
3.4.1 登录会话
所有 Jakarta EE Web 服务器必须为每个 Web 用户维护一个登录会话。登录会话必须能够跨多个应用存在，允许用户一次登录即可访问多个应用。Servlet 规范中描述了所需的登录会话支持。为每个 Web 用户提供会话的这一要求，是为了支持单点登录。
应用可以独立于登录信息的安全实现与维护细节。Jakarta EE 产品提供商可以灵活选择认证机制，而无需考虑受这些机制保护的应用。
Web 服务器必须对受保护的 Web 资源支持延迟认证。当需要进行认证时，可以使用下一节列出的三种必选登录机制之一。
3.4.2 必选登录机制
所有 Jakarta EE 产品都必须支持三种登录机制：HTTP 基本认证、SSL 双向认证和基于表单的登录。应用不强制使用其中任何一种机制，但这些机制必须对所有应用可用。
3.4.2.1 HTTP 基本认证
所有 Jakarta EE 产品都必须支持 HTTP 基本认证（RFC2068）。平台提供商还必须支持基于 SSL 的基本认证。
3.4.2.2 SSL 双向认证
本规范要求必须支持 TLS 1.2 以及基于证书实现双向（客户端与服务端）身份认证的相关机制。
所有 Jakarta EE 产品还必须支持 TLS 1.1 和 TLS 1.0，以保障与客户端之间可实现具备互操作性的安全通信；但在特定部署场景下，若无需使用 TLS 1.0，则应将其禁用；TLS 1.1 同理，无需使用时可禁用。
同样，为保障与客户端之间可实现具备互操作性的安全通信，所有 Jakarta EE 产品必须支持以下密码套件：
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
同时建议使用客户端与服务端之间可协商的强度最高的密码套件；在特定部署场景下，若无需使用上述密码套件，可将其禁用，改用安全性更强的密码套件。
请注意，本规范的早期版本要求支持 SSL 3.0 以及以下密码套件：
- TLS_RSA_WITH_RC4_128_MD5
- SSL_RSA_WITH_RC4_128_MD5
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- SSL_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL 3.0 已于 2015 年通过 RFC 7568 被正式弃用，并且在许多 TLS 实现中默认不支持或已被禁用。上述所有密码套件目前均不再被认为是安全的，也可能默认不被支持或已禁用。 在极少数情况下，为了与旧版客户端或旧版 Jakarta EE 实现互操作，可能需要使用 SSL 3.0 或协商使用上述某一密码套件。但建议尽可能使用 TLS 1.0 及更高版本，并协商安全性更强的密码套件。 若在特定部署环境中无需为兼容互操作而使用，则应禁用 SSL 3.0 以及上述列出的密码套件。
3.4.2.3 基于表单的登录
Web 应用部署描述符中包含一个元素，该元素使 Jakarta EE 产品将 HTML 表单资源（可能是动态生成的）与 Web 应用相关联。如果部署者选择这种表单认证方式（而非 HTTP 基本认证或基于 SSL 证书的认证），则该表单必须用作用户登录应用的界面。
基于表单的登录机制以及 Web 应用部署描述符在 Servlet 规范中有详细说明。
3.4.3 未认证用户
Web 容器必须支持未向容器完成身份认证的客户端访问 Web 资源，这是互联网上访问 Web 资源的通用方式。
Web 容器通过以下方式标识当前无用户认证：
SecurityContext接口的getCallerPrincipal方法返回nullHttpServletRequest接口的getUserPrincipal方法返回null
这与 EJBContext 的 getCallerPrincipal 方法行为不同：Jakarta Enterprise Beans 规范要求该方法始终返回合法的 Principal 对象，永远不会返回 null。而 SecurityContext 的 getCallerPrincipal 即使在 Jakarta Enterprise Beans 容器中调用，对匿名用户仍会返回 null。
对于同时包含 Web 容器与 Jakarta Enterprise Beans 容器的 Jakarta EE 产品，即使 Web 容器中无用户认证，运行在 Web 容器中的组件也必须能够调用企业 Bean。 当 Web 容器中的组件在此场景下调用企业 Bean 时，Jakarta EE 产品必须为该调用提供一个主体（Principal）。
Jakarta EE 产品可通过多种方式为未认证调用方提供主体，包括但不限于：
- 始终使用同一个特定主体
- 按服务器、会话或应用使用不同的特定主体
- 通过 Web 容器与企业 Bean 容器的 Run As（以指定身份运行） 能力，允许部署者或系统管理员选择所用主体
本规范未规定 Jakarta EE 产品应如何选择代表未认证用户的主体，未来版本可能会增加这方面的要求。 注意：使用 Jakarta Enterprise Beans 互操作协议时，相关规范已包含此领域的要求。 建议在 Web 组件可能处于未认证状态但需要调用 Jakarta Enterprise Beans 组件时，应用使用 Run As 能力。
3.4.4 应用客户端用户认证
应用客户端容器必须提供应用用户的身份认证功能，以满足企业 Bean 容器和 Web 容器所实施的认证与授权约束。所采用的具体技术可能随应用客户端容器的实现不同而有所差异，且不受应用本身控制。应用客户端容器可以与 Jakarta EE 产品的认证系统集成，以提供单点登录能力；或者容器也可在应用启动时对用户进行认证。容器还可以将认证推迟到访问受保护资源或企业 Bean 的请求发生时再执行。
容器将提供合适的用户界面与用户交互，以收集认证信息。此外，应用客户端可以提供一个实现了 javax.security.auth.callback.CallbackHandler 接口的类，并在其部署描述符中指定该类名（详情参见 Jakarta EE 应用客户端 XML 模式）。部署者可以覆盖应用指定的回调处理器，转而要求使用容器默认的认证用户界面。
如果部署者已配置使用某个回调处理器，则应用客户端容器必须实例化该类的对象，并使用它完成所有与用户的认证交互。应用的回调处理器必须支持 javax.security.auth.callback 包中定义的所有 Callback 对象。
3.4.5 资源认证要求
企业内部的资源，通常部署在与应用组件所属安全策略域不同的域中。用于对调用方进行资源认证的机制种类繁多，因此要求 Jakarta EE 产品提供在资源所属安全策略域中完成认证的能力。
产品提供商必须同时支持以下两种方式：
配置身份
Jakarta EE 容器必须能够使用部署者在部署时指定的主体和认证数据，进行资源访问认证。该认证不得依赖应用组件提供的任何数据。产品提供商负责对认证信息进行安全存储。
编程式认证
Jakarta EE 产品必须允许应用组件在运行时通过合适的 API，指定访问资源所需的主体与认证数据。应用可以通过多种途径获取这些主体和认证数据，包括以参数形式接收、从组件环境中获取等。
此外，以下技术属于推荐实现，但本规范不做强制要求：
主体映射（Principal Mapping） 资源可以拥有一组主体与属性，这些主体和属性通过映射请求方主体的身份与安全属性来确定。在这种情况下，资源主体并非继承请求方主体的身份或安全属性，而是基于映射规则获得自身的身份与安全属性。
调用方模拟（Caller Impersonation） 资源主体代表请求方主体执行操作。代表调用方主体执行操作，需要将调用方的身份与凭证委托给底层资源管理器。在某些场景中，请求方主体本身可能是初始主体的代理人，此时资源主体会通过传递关系模拟初始主体。
对主体委托的支持通常与具体安全机制相关。例如，Kerberos 提供了认证委托机制（更多细节请参考 Kerberos v5 规范）。
凭证映射（Credentials Mapping） 当应用服务器与企业信息系统（EIS）属于不同认证域时，可使用该技术。例如：
- 初始主体已完成认证，并拥有基于公钥证书的凭证；
- 资源管理器的安全环境配置为使用 Kerberos 认证服务；
- 应用服务器被配置为将与初始主体关联的、基于公钥证书的凭证映射为 Kerberos 凭证。
有关资源认证要求的更多信息，可参见《Jakarta 连接器规范》。