How do I do security in JSF?

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 roug

Answer 1

The simplest approach is

<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>

Answer 2

Showing multiple versions of the same page is not about security (different version != links hiding), restricting access and requiring additional authorization is, I'll answer that if you dont mind.

You can read about both (authentication, authorization) on JAAS page. It is also the best framework in my opinion. It takes some time to master but after then, it's pretty easy and you'll even realize it's not heavy-weight at all - you're not forced to use every single feature. (just like EJB)

JAAS can log you even using ldap or windows account, theres even support for multiple authentication steps - you can implement pass+sms login. You can do that even with acegi, of course (it's just not that easy)

Since you've already mentioned JSF, JAAS fits even better than acegi, you can annotate any backing bean with @RolesAllowed and if user session does not meet requirements, SecurityException will be thrown. This works for servlets and beans (ejb, backing), not for jsps (however it wouldnt make much sense anyway)

You can read about @RolesAllowed here, but if you're already considering it, don't miss JBoss Seam Security - it's built on top of both security annotations and JAAS and it's also pretty addictive to use. Worth of reading.

BTW guys: I'm not rep-whoring, just found interesting question so... feel free to fight for bounty :)

Answer 3

Usually this kind of content will be held in the session variables. So you do not have to think about what user is logged in.

Answer 4

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.