Win a copy of Learning Regular Expressions this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

JSF and Security  RSS feed

 
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?
 
Bartender
Posts: 19735
92
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!