• Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF and Security  RSS feed

 
Chris Boldon
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the best practice for implementing security into a JSF application?
 
Tim Holloway
Bartender
Posts: 18663
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't expect an unbiased answer from me on this one - it's one of my favorite things to rant about. So here goes:

I strongly recommend using the built-in (container-based or "CBS" for short ) security - system that's part of the J2EE/JEE framework definition. I could probably list 10 compelling reasons, starting with the fact that few do-it-yourself security "experts" are as clever as they think they are and going on the fact that over their lifespan, a container-based app is generally going to be cheaper and more reliable. But for today, I'll keep it short.

CBS is built into the JEE (and J2EE) standard. It's always going to be there, whether you use it or not. The JSF standard was designed to work in conjunction with it. So, for that matter, is Struts, though unlike JSF, Struts wasn't obligated to, since it's not part of the standard.

Because CBS is externally applied, the actual amount of your app that has to be security-aware is kept to a minimum. This can be very helpful, since you can develop and test a lot of the system without doing any security development/debugging at all, then switch it on when you're ready. In contrast, I've seen internal security systems end up strangling every app function; since there's they're non-standard, the internal security is often as mutable as the application itself, and you end up debugging both it and the app at the same time.

The one place where CBS can be a problem has to do with JSF's kinky URL mechanism, which is often a problem no matter what, if any, security system is in effect. However, I've been successful by partitioning the app sub-URL's into functional components, such as "/admin" for administrative functions. This also works for Struts, where I learned very early that the popular practice of simply dumping all the form beans into one package, all the action processors in another package and so forth has more than one reason to be avoided.

I won't claim that CBS is the Ultimate and Final solution to all security needs, but I've run across few systems complex enough to need more and so far all of those have been able to layer their additional functions on top of CBS.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!