我如何在 JSF 中进行安全保护? [英] How do I do security in JSF?
问题描述
我将 Java EE 6 与所有参考实现一起使用.对某些页面(例如 /secure/* 下的所有内容)进行了一些安全限制.这是粗粒度的安全性.如果两个用户都具有相同的角色，但例如同一页面的某些内容应该只对用户John"可见，该怎么办?或者应该向约翰"显示一个完全不同的页面?我有很多问题没有回答，所以如果有人能提供一些链接/解释或涵盖这一点的书籍，那就太好了.我需要更细粒度的安全控制.
您希望的细粒度安全功能不仅存在，Oracle 甚至还有 一篇详细介绍该主题的有用博客文章，并附有示例代码.
而且因为我简单地链接文档并运行是简洁和不礼貌的，下面是关于如何按照我的理解结合在一起的一些讨论.
第0个问题:粗粒度的声明式安全
声明式安全的最大问题是它迫使您反复定义您在设计时的所有用户角色.这是极不可取的，原因有二:首先，它未能正确地将您的安全模型从您的实现中抽象出来(未能充分面向未来您的应用程序并打开了信息泄露漏洞的大门)，其次，它将您的用户角色与应用程序的直接设计联系在一起，通常无法提供细粒度的权限或ACL(在需要或必要时).
实际上，这是一个抽象不足的问题.您使用的系统可以立即满足您当前的需求，但随着角色变得越来越复杂且代码库的复杂性不断增加，您所使用的系统在应用程序的整个生命周期中都无法运行或可维护.
使用托管 Bean 的细粒度安全
这里的一阶解决方案是使用一个抽象模型，它允许您在每个 JSF 方法调用的上下文中独立定义用户角色，允许您根据需要将它们换入或换出.作为奖励，这允许您定义细粒度权限，因为这样的方案允许您定义权限每个方法而不是每个视图、每个端点或每个豆角，扁豆.如果角色发生变化?您只需要在一个位置更新您的权限模型，而无需访问每个 bean 并换出它们的用户定义.
前面链接的文章比我在此愿意介绍的要详细得多，所以我强烈建议阅读博客文章.但是这里的要点是，要正确地做到这一点，您应该同时提供一个身份验证堆栈和一个详细说明权限角色的注释层， 并且两个人只会在您遇到的地方相遇明确而有意地将两者联系起来.
定义细粒度的方法调用和有意义的安全策略留给读者作为练习，但如果您有这方面的问题，请随时在评论或一组后续中提问问题，因为这些问题本质上对广大受众有用.
改进
可以想象，此解决方案不足以满足您的需求.例如，如果您希望使用 LDAP 或 Kerberos 提供您的用户和角色的统一表示，这仅提供了部分解决方案来满足您的需求.几个很棒 resources 存在于该域中，但是这留作练习给读者.
这里的最终结论是，在完美的世界中，您的应用程序安全性应该是这样定义的.您的需求可能会有所不同，对于小规模的东西，简单的声明式安全性可能足以满足您的需求.毕竟，这就是它继续存在的原因.
但是，对于必须安全、正确地满足大量用户需求的大型应用程序，这是正确的方法.它需要更多的知识和开销，但如果您以正确的方式开始，它将为您节省大量的时间、精力和挫折.
一如既往，祝您申请顺利.
I am using Java EE 6 with all reference implementations. Having made some security constraints for some pages such as everything beneath /secure/*. This is rough grained security. What if two users both have the same roles, but some content of the same page should only be visible to user "John" for example? Or a totally different page should be shown to "John"? I have many questions un-answered around this so it would be nice if somebody could provide some links/explanations or books that cover this as well. I need more fine grained security control.
The fine-grained security features you're hoping for not only exist, Oracle even has a useful blog post covering the subject in detail, complete with sample code.
And because it would be terse and impolite of me to simply link the docs and run, what follows is a bit of discussion on how this goes together to the best of my understanding.
The 0th problem: rough-grained, declarative security
The biggest problem with declarative security is it forces you to iteratively define all of your user roles at design time. This is extremely undesirable for two reasons: first, it fails to properly abstract your security model away from your implementation (failing to adequately future-proof your application and opening the door to information disclosure vulnerabilities), and second, it tethers your user roles to the immediate design of your application, routinely failing to provide fine-grained permissions or ACLs when they're desired or necessary.
In effect, this is a problem of insufficient abstraction. You're using a system that immediately meets your current needs, but not one that you can expect to be workable or maintainable over the life cycle of your application, as roles become more complex and the complexity of your code base steadily increases.
Fine-grained security using Managed Beans
The first-order solution here is to use an abstraction model that allows you to define user roles independently in the context of each JSF method call, allowing you to swap them in or out as needed. As a bonus, this allows you to define finer-grained permissions, as such a scheme allows you to define your permissions per method instead of per view, per endpoint, or per bean. And if the roles change? You only need to update your permissions model in a single location, instead of going to each of those beans and swapping out their user definitions.
The aforelinked article goes into far more detail than I'm willing to cover here, so I highly recommend reading the blog post. But the takeaway here is, to do this properly, you should provide both an authentication stack and an annotation layer detailing permission roles, and the twain shall only meet where you've explicitly and deliberately connected the two.
Defining fine-grained method calls and a security policy that makes sense is left as an exercise for the reader, but if you have questions in this area, feel free to ask them in the comments or in a set of follow-up questions, as these questions are inherently useful to a wide audience.
Improvements
It's conceivable that this solution isn't robust enough for your needs. For example, if you wish to authenticate users using LDAP or Kerberos to provide a unified representation of your users and roles, this only provides a partial solution to meet your needs. Several great resources exist in this domain, but this is otherwise left as an exercise for the reader.
The ultimate takeaway here is, in the perfect world, this is how your application security should be defined. Your needs may vary, and for something left at the small scale, simple, declarative security may be fine to meet your needs. After all, that's why it continues to exist.
But, for larger applications that must meet the needs of a large number of users securely and correctly, this is the right way to go. It requires a bit more knowledge and overhead, but it'll save you copious amounts of time, effort, and frustration if you begin by doing it properly.
As always, best of luck with your application.
这篇关于我如何在 JSF 中进行安全保护?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
