我正在使用Java EE 6和所有参考实现。对某些页面进行了一些安全约束，例如/secure/*下的所有内容。这是粗粒度的安全性。例如，如果两个用户都具有相同的角色，但同一页面的某些内容应该只对用户"John"可见，该怎么办？还是应该向"约翰"显示完全不同的页面？我有很多问题没有回答，所以如果有人可以提供一些链接/解释或书籍来涵盖这一点，那就太好了。我需要更细粒度的安全控制。
细粒度安全功能不仅存在，Oracle 甚至还有一篇有用的博客文章详细介绍了该主题，并附有示例代码。
而且因为简单地链接文档并运行对我来说是简洁和不礼貌的，所以接下来是关于如何尽我所能进行的一些讨论。
第 0 个问题：粗粒度、声明式安全性
声明性安全性的最大问题是它强制您在设计时以迭代方式定义所有用户角色。这是非常不可取的，原因有两个：首先，它无法正确地将您的安全模型从实现中抽象出来（未能充分证明您的应用程序面向未来，并为信息泄露漏洞打开大门），其次，它将您的用户角色束缚在应用程序的直接设计中，通常无法在需要时或必要时提供细粒度的权限或 ACL。
实际上，这是一个抽象不足的问题。您正在使用的是一个可以立即满足当前需求的系统，但随着角色变得越来越复杂，代码库的复杂性也在稳步增加，您不能期望在应用程序的生命周期中可行或可维护的系统。
使用托管 Bean 的细粒度安全性
此处的一阶解决方案是使用抽象模型，该模型允许您在每个 JSF 方法调用的上下文中独立定义用户角色，从而允许您根据需要交换用户角色。作为奖励，这允许您定义更细粒度的权限，因为这样的方案允许您按方法定义权限，而不是按视图、按端点或按 Bean。如果角色发生变化？您只需要在单个位置更新权限模型，而无需转到每个 Bean 并交换其用户定义。
上述链接的文章比我愿意在这里涵盖的要详细得多，所以我强烈建议阅读博客文章。但这里的要点是，要正确地做到这一点，您应该提供一个身份验证堆栈和一个详细说明权限角色的注释层，并且 twain 只有在您明确和有意地将两者连接的地方才能满足。
定义细粒度的方法调用和有意义的安全策略留给读者作为练习，但如果您在这方面有疑问，请随时在评论或一组后续问题中提出，因为这些问题本质上对广大受众有用。
改进
可以想象，此解决方案不足以满足您的需求。例如，如果您希望使用 LDAP 或 Kerberos 对用户进行身份验证，以提供用户和角色的统一表示形式，则这仅提供部分解决方案来满足您的需求。这个领域存在几个很好的资源，但除此之外，这留给读者练习。
这里的最终结论是，在理想情况下，这就是应该如何定义应用程序安全性。您的需求可能会有所不同，对于小规模的东西，简单的声明性安全性可能可以满足您的需求。毕竟，这就是它继续存在的原因。
但是，对于必须安全正确地满足大量用户需求的大型应用程序，这是正确的方法。它需要更多的知识和开销，但如果您一开始做得好，它会为您节省大量的时间、精力和挫败感。
与往常一样，祝您的应用程序好运。
最简单的方法是
<h:panelGroup rendered="#{request.userPrincipal.name == 'user1'}">
<p>Content for user 1</p>
</h:panelGroup>
<h:panelGroup rendered="#{request.userPrincipal.name == 'user2'}">
<p>Content for user 2</p>
</h:panelGroup>
显示同一页面的多个版本与安全性无关（不同版本！=链接隐藏），限制访问并需要额外的授权是，如果您不介意，我会回答。
您可以在 JAAS 页面上阅读有关两者（认证、授权）的信息。在我看来，这也是最好的框架。掌握需要一些时间，但在那之后，它很容易，你甚至会意识到它根本不是重量级的 - 你不会被迫使用每一个功能。（就像EJB一样）
JAAS甚至可以使用LDAP或Windows帐户记录您，甚至支持多个身份验证步骤 - 您可以实现pass+sms登录。当然，即使使用 acegi，您也可以做到这一点（这并不容易）
由于您已经提到了 JSF，JAAS 甚至比 acegi 更适合，您可以使用 @RolesAllowed 注释任何支持Bean，如果用户会话不满足要求，则将抛出SecurityException。这适用于servlet和bean（ejb，backing），不适用于jsps（但是无论如何它没有多大意义）
你可以在这里阅读@RolesAllowed，但如果你已经在考虑它，不要错过JBoss Seam Security - 它建立在安全注释和JAAS之上，使用起来也很容易上瘾。值得一读。
顺便说一句，伙计们：我不是嫖娼，只是发现了有趣的问题，所以......随意争取赏金:)
通常，此类内容将保存在会话变量中。因此，您不必考虑登录的用户。