Question

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.

Answer 1

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.