有几个选项. Select 哪一个完全由你决定.客观地权衡具体的利弊，符合自己的情况.

1. Use Java EE provided container managed authentication

只需在web.xml中声明<security-constraint>，它引用在servlettainer中配置的安全领域.您可以为您的Web应用程序指定应判断登录和/或角色的URL模式，例如/secured/*、/app/*、/private/*等.

遗憾的是，在JavaEE8之前，您仍然需要以特定于servlettainer的方式配置安全领域.它通常在特定于servletconainer的文档中描述.在Tomcat8的情况下，这是Realm HOW-TO.例如，"JDBCRealm"一节描述了基于用户/角色表的基于数据库的领域.

从JavaEE8开始，最终将有一个基于JSR-375的标准API.

优势:

• 相对快速且易于设置和使用.
• 从JavaEE8开始，终于有了健壮而灵活的标准API.

缺点:

• 在JavaEE8之前，领域配置是特定于容器的.在JavaEE8中，新的JSR-375 Security Spec应该在JASPIC的帮助下解决这个问题.
• 在JavaEE8之前，没有细粒度控件.
• 在JavaEE8之前，它非常简单；没有"记住我"，差劲的错误处理，没有基于权限的限制.

另请参阅:

• Performing user authentication in Java EE / JSF using j_security_check-包含完整的代码示例
• Java EE kickoff application个示例Web应用程序(由我开发)，它还演示了使用Soteria(JSR-375RI)进行JavaEE8身份验证.

2. Homegrow a servlet filter

这允许更细粒度的控制，但是您将需要自己编写所有代码，并且您应该真正知道/理解应该如何实现这样的过滤以避免潜在的安全漏洞.例如，在JSF端，您只需将登录的用户作为会话属性减go sessionMap.put("user", user)，如果session.getAttribute("user")不是null，则签入过滤.

优势:

• 细粒度控制.
• 完全独立于容器.

缺点:

• 轮子的重新发明；新功能需要大量代码.
• 作为初学者，您永远不能确定您的代码是否100%健壮.

另请参阅:

• Is there any easy way to preprocess and redirect GET requests?-包含身份验证的介绍性说明和启动示例
• Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same-包含更多扩展的身份验证启动示例，该示例还涵盖Ajax请求
• How control access and rights in JSF?-包含授权的启动示例

3. Adapt a 3rd party framework

例如，Apache Shiro、Spring Security等.这通常提供比标准容器管理身份验证更细粒度的配置选项，您不需要为此自己编写任何代码，当然，登录页面和一些(XML)配置除外.

优势:

• 细粒度控制.
• 完全独立于容器.
• 没有轮子的翻新；最低限度的自己的代码.
• 经过大量用户的全面开发和测试，所以很可能100%健壮.

缺点:

• 一些学习曲线.

另请参阅:

• JSF2 - Shiro tutorial-关于在JSF2WebApp中集成Shiro的广泛教程