所以，请建议下列选项是否有效，以及关于优点或缺点的说明。这可能是我错过了可能使身份验证方法可行的细节。或者也许有另外一个选择我错过了(再次，我们正在严格地说Java EE，所以没有查询身份验证，除非可以按照EE兼容的方式)
1. DIGEST/BASIC authentication
<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调用发送授权凭据。一旦用户认证，浏览器将伴随任何请求与适当的授权：基本/摘要QWxhZGRpbjpvcGVuIHNlc2FtZQ ==标头。如果凭证不正确，用户将会看到丑陋的浏览器登录屏幕 – 如果您可以使用该功能，那么BASIC / DIGEST auth就是您的方式。
>在Digest的情况下，传递给服务器的字符串是一个MD5加密字符串，它比Basic(这是“user：password”字符串的Base64编码)更安全，但是仍然为decipherable.所以在安全性方面BASIC与FORM认证几乎一样安全，DIGEST是其中最安全的。总而言之，如果您的站点完全是HTTPS(我的意思是完全是因为如果通过HTTP获取了一些资源，那么您的授权头可能对第三方可见)，您可以安全地使用BASIC / DIGEST。
>易于设置
缺点
注销是棘手的实现。请参阅here和here。您有一个很好的AJAX请求，用于验证用户，但您还需要一个AJAX？请求登录用户 – 触发浏览器登录窗口再次出现)。 BTW的好servlet 3.0 request.logout()方法does not work properly in this case。
>会话超时很难实现。会话过期确实发生(它是servlet容器的工作)，但浏览器会在下次请求时发送授权头，触发重新认证。
>没有个性化登录页面。没有。
>很难跟踪认证会话。
2. FORM based authentication
<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>
长篇小说，如果用户访问受保护的/ * url，登录页面将包含在响应中。因此，用户期望他将获得form-login-page标签中配置的登录页面而不是内容。如果密码正常，他将被转发(302 Paged Moved Permanently)到最初请求的protected / * url。如果密码为NOK，用户将被转发(302 Paged Moved Permanently)到错误页面。
优点
>个性化登录页面 – 这个似乎是最受欢迎的:)
>注销很容易实现。一个需要只使HttpSession无效或调用request.logout()方法(Servlet 3.0)。
>会话超时
> IF和ONLY如果您接受单独的登录页面，这是您的解决方案。
缺点
> REST不友好(我不会挖掘休息的哲学，保持服务器端状态不是RESTful辩论，我们正在以JAVA EE方式分析REST身份验证，服务器端状态始终保持为任何身份验证的主题)。使用FORM身份验证真的很糟糕的事实是，跨浏览器不能保持一致的行为。这一切都是由于一些浏览器在AJAX响应函数中处理的302重定向，而其他重定向则导致整个页面(更改导航栏中的URL)。更多细节here和here.你不能解决302重定向，所以没有FORM和REST身份验证你先生！
3. Programmatic authentication
设置验证URL。在该URL后面，您可以有一个实例化一个登录模块(JAAS方式)的servlet并调用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设置为这样做)
>会话超时(容器管理)
>您可以在响应中返回登录数据(用户名，电子邮件，角色，组等)(reaaaallly nice，因为您在登录成功后不必再进行其他呼叫)
缺点
>需要一些代码写作。
>需要应用程序才能处理401/403响应并显示登录窗口
总而言之，最好的可行选择：
>如果您不关心会话超时或注销 – >消化
>如果上述不适用于您，并且您不需要嵌入式登录页面(或模式面板类页面)，并且您可以使用一个单一页面进行身份验证 – >形成
>如果上述不适用于您，并且您希望世界上所有的灵活性和兼容性都遵循PROGRAMMATIC方法。您必须定义登录/注销URL，并且您的客户端代码应该能够应对401/403响应(不容易)。
真的很期待你们建议一些可行的替代解决方案。因为现在我会用PROGRAMMATIC方法去讨论
它还取决于首选的服务器实现。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。