There are many ways to do this. Most of which shouldn't be done, but people do them anyway.
One way, however, is to use J2EE's built-in security system (also known as container-managed security). If you use this system, you don't actually "do security in JSF" so much as you wrap security around your entire webapp, including any non-JSF parts it may contain.
To accomplish this, you need to do 2 things:
1. Code security as documented by the J2EE standard and explained in many, if not most good books on J2EE. This primarily means setting up definitions in web.xml. The only thing JSF-specific about this is that critical page navigation rules should include a <redirect/> element, or the URL won't update. And the URL is the primary definer of what security rules will apply.
2. Supply a security provider. For Tomcat, that would be a Realm module. Tomcat doesn't come with a Web Services Realm module, but it's quite easy to create one. I've done it.
For the most part, you don't need to code security in the application, because Tomcat itself will be providing the security. When you need to add extra control, you can check roles, or use the user ID that's in the HttpServletRequest as a key to a more fine-grained security service of your choice.
The way I don't recommend doing it is to have the webapp implement and use a security interface directly. People who do that aren't security professionals, and such systems are pretty much always very insecure. Plus, it takes a lot of time and money to design, develop, debug and maintain a DIY system. And you can't send junior programmers down to the local bookstore for documentation on how to use it (so when maintenance time comes, they either do it wrong or not at all).
Customer surveys are for companies who didn't pay proper attention to begin with.