我正在使用 Java EE 6 和所有引用实现。对某些页面进行了一些安全限制，例如 /secure/* 下的所有内容。这是粗粒度的安全性。如果两个用户都具有相同的角色，但同一页面的某些内容只能对用户“John”可见，该怎么办？或者应该向“John”显示一个完全不同的页面？我对此有很多未解答的问题，因此如果有人可以提供一些涵盖此问题的链接/解释或书籍，那就太好了。我需要更细粒度的安全控制。
最佳答案
您所希望的细粒度安全功能不仅存在，Oracle甚至拥有a useful blog post covering the subject in detail ，并附有示例代码。
因为简单地链接文档并运行对我来说是简洁且不礼貌的，所以接下来是一些关于如何根据我的理解将其结合在一起的讨论。
第 0 问题:粗粒度、声明式安全性
最大的问题是declarative security它是否迫使您在设计时迭代地定义所有用户角色？这是极其不可取的，原因有两个:首先，它无法正确地将安全模型从实现中抽象出来(未能充分future-proof您的应用程序并打开信息泄露漏洞的大门)，其次，它将您的用户角色与应用程序的直接设计联系起来，通常无法提供细粒度的权限或ACLs当需要或有必要时。
实际上，这是一个抽象不足的问题。您正在使用的系统可以立即满足您当前的需求，但随着角色变得更加复杂并且代码库的复杂性稳步增加，您可以期望该系统在应用程序的生命周期中不可用或可维护。
使用托管 Bean 实现细粒度安全性
这里的首要解决方案是使用抽象模型，该模型允许您在每个 JSF 方法调用的上下文中独立定义用户角色，从而允许您根据需要将它们换入或换出。作为奖励，这允许您定义更细粒度的权限，因为这样的方案允许您定义每个方法的权限，而不是每个 View 、每个端点或每个 bean 。如果角色发生变化呢？您只需要在一个位置更新您的权限模型，而不是转到每个 bean 并交换它们的用户定义。
aforelinked article所涉及的细节比我愿意在这里介绍的要详细得多，因此我强烈建议您阅读该博客文章。但这里的要点是，要正确地做到这一点，您应该提供身份验证堆栈和详细说明权限角色的注释层，并且两者只能在您已经满足的地方满足明确且有意地将两者联系起来。
定义细粒度的方法调用和有意义的安全策略留给读者作为练习，但如果您在这方面有疑问，请随时在评论或一系列后续内容中提问问题，因为这些问题本质上对广大受众有用。
改进
可以想象，该解决方案不够强大，无法满足您的需求。例如，如果您希望使用 LDAP 对用户进行身份验证或Kerberos为了提供用户和角色的统一表示，这仅提供了满足您需求的部分解决方案。几个great resources存在于这个域中，但这作为读者的练习。
这里的最终结论是，在完美的世界中，这就是您的应用程序安全性的定义方式。您的需求可能会有所不同，对于小规模的东西，简单的声明式安全性可能足以满足您的需求。毕竟，这就是它继续存在的原因。
但是，对于必须安全、正确地满足大量用户需求的大型应用程序，这是正确的方法。它需要更多的知识和开销，但如果您一开始就正确地执行它，它将为您节省大量的时间、精力和挫败感。
一如既往，祝您申请顺利。
关于security - 如何在 JSF 中实现安全性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10154202/