我已经花费了一些时间来评估可用于在Java EE应用程序中轻松地对用户进行身份验证的选项。
因此，请建议下面列出的选项是否有效以及有关优点或缺点的陈述。可能是我遗漏了可能使身份验证方法可行的细节。或者可能是我错过了另一个选项（我们再次严格地谈论 java EE，所以没有查询身份验证，除非它可以以符合 EE 的方式完成，否则不会）
1. DIGEST/BASIC 认证
<security-constraint>
<web-resource-collection>
<web-resource-name>admin</web-resource-name>
<url-pattern>/protected/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>DIGEST/BASIC</auth-method>
<realm-name>as-defined-secuity-realm</realm-name>
</login-config>
优点
这是一种 REST 友好的身份验证方式。您可以通过 AJAX 调用发送授权凭据。一旦用户通过身份验证，浏览器将伴随任何带有正确
Authorization: Basic/Digest QWxhZGRpbjpvcGVuIHNlc2FtZQ==标头的请求。如果凭据错误，用户将看到丑陋的浏览器登录屏幕 - 如果您可以忍受，那么 BASIC/DIGEST auth 就是适合您的方式。在 Digest 的情况下，传递给服务器的字符串是一个 MD5 加密字符串，它绝对比 Basic（它是 'user:password' 字符串的 Base64 编码）更安全，但仍然是可解密的。所以就安全性而言，BASIC 几乎与 FORM 身份验证一样安全，而 DIGEST 是其中最安全的。总之，如果您的网站完全是 HTTPS（我的意思完全是因为如果通过 HTTP 获取某些资源，例如您的授权标头将对第三方可见），那么您可以安全地使用 BASIC/DIGEST。
- 易于设置。
缺点
- 注销很难实现。请参阅此处和此处。当然，您有一个很好的 AJAX 请求来验证用户，但您还需要一个？AJAX？注销用户的请求 - 触发浏览器登录窗口再次出现）。顺便说一句，nice servlet 3.0 request.logout() 方法在这种情况下无法正常工作。
- 会话超时很难实现。会话过期确实会发生（这是 servlet 容器的工作），但浏览器将在下一个请求时发送授权标头，从而触发重新身份验证。
- 没有个性化的登录页面。没有任何。
- 很难跟踪经过身份验证的会话。
2.基于FORM的认证
<security-constraint>
<web-resource-collection>
<web-resource-name>admin</web-resource-name>
<url-pattern>/protected/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>as-defined-security-realm</realm-name>
<form-login-config>
<form-login-page>/auth/login.html</form-login-page>
<form-error-page>/auth/error.html</form-error-page>
</form-login-config>
</login-config>
长话短说，如果用户访问一个protected/*url，则登录页面将包含在响应中。因此，用户将获得form-login-page标签中配置的登录页面，而不是用户期望的内容。如果密码正确，他将被转发（302 Paged Moved Permanently）到最初请求的protected/*url。如果密码为 NOK，用户将被转发（302 Paged Moved Permanently）到错误页面。
优点
- 个性化登录页面 - 这似乎是最受欢迎的 :)
- 注销很容易实现。只需使 HttpSession 无效或调用 request.logout() 方法（Servlet 3.0）。
- 会话超时
- 如果且仅当您接受使用单独的登录页面时，这才是适合您的解决方案。
缺点
- REST 不友好（我不打算深入研究 REST 的原理，保持服务器端状态不是 RESTful 辩论。我们正在以 JAVA EE 方式分析 REST 身份验证，并且始终为任何经过身份验证的主题维护服务器端状态） . 使用 FORM 身份验证的真正糟糕之处在于，人们无法在浏览器之间保持一致的行为。这完全是由于一些浏览器在 AJAX 响应函数中处理的 302 重定向，而另一些浏览器则重定向整个页面（在导航栏中更改 URL）。更多细节在这里和这里。您无法解决该 302 重定向问题，因此您无需进行 FORM 和 REST 身份验证！
3.程序化认证
设置用于身份验证的 URL。在该 URL 后面，您可以有一个 servlet，它实例化登录模块（JAAS 方式）并调用 HttpServletRequest.login(user,pass) 方法以及凭据。如果登录失败，它应该生成 401/403 响应。
您可以通过在 web.xml 中指定安全约束来实现它：
<security-constraint>
<web-resource-collection>
<web-resource-name>admin</web-resource-name>
<url-pattern>/protected/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
在服务器端，您只需要设置一个 RESTFul 服务来对调用者进行身份验证。这是一些示例代码：
@Path("/auth")
@ApplicationPath("/rest")
public class AuthenticationRestFacade {
@POST
@Path("/login")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public User login(User loginInfo, @Context HttpServletRequest request) throws LoginException, ServletException {
// nasty work-around for Catalina AuthenticatorBase to be able to
// change/create the session cookie
request.getSession();
request.login(loginInfo.getName(), loginInfo.getPassword());
优点
- 个性化的登录页面。
- AJAX/REST 兼容
- 注销 URL（如果设置了 URL）
- 会话超时（容器管理）
- 您可以在响应中返回登录数据（用户名、电子邮件、角色、组等）（非常好，因为您不必在成功登录后再次调用）
缺点
- 需要一些代码编写。
- 需要应用程序能够处理 401/403 响应并显示登录窗口
总而言之，最好的可行选择：
- 如果您不关心会话超时或注销 --> DIGEST
- 如果上述方法对您不起作用并且您不需要嵌入的登录页面（或类似模式面板的页面）并且您可以使用一个页面进行身份验证-> FORM
- 如果上述方法对您不起作用，并且您希望世界上所有的灵活性和兼容性都采用 PROGRAMMATIC 方法。您必须定义登录/注销 URL，并且您的客户端代码应该能够处理 401/403 响应（不容易）。
真的期待你们提出一些可行的替代解决方案。因为现在我讨厌采用 PROGRAMMATIC 方法