I ended up using a servlet filter so that I can protect all resources, not just JSF. The phase listener approach was fine for securing JSF pages, but not CSS, JS, PNG, etc. files. So I decided to move my code out of the phase listener and add it to a servlet filter instead.
That takes care of URL security, but for JSF security I leveraged JBoss-Seam. I created new annotations for security permissions that I ensure that when a managed bean is accessed, the current user is in the correct role. That way, the view is not secured per-say, but instead the business code is secure. Because really, the view file contains no proprietary information, the data from the managed beans is the sensitive data. Although non-standard, it has fit our needs quite well. If you wanted to secure JSF views, you could combine container managed (or a custom servlet filter) for static resources (CSS, etc.) and use a phase listener to secure views. The major issue with using a servlet filter in securing a view is that the view is created after the post, so that the current URL does not equal the current view necessarily. Thus securing on URL doesn't necessarily secure the correct JSF view. Hence why a phase listener would be better for security JSF views. If you are insterested in my approach of using Seam, check out: http://docs.jboss.com/seam/latest/reference/en/html/concepts.html#d0e2635 On 11/7/06, Jeff Bischoff <[EMAIL PROTECTED]> wrote:
Andrew, I was curious to see what you ended up using. I saw some comments previously, and in the mail archives, that made me think you were trying the phase listener approach. (See [1] and [2]) If so, how did that end up for you? What prompted you to move to a servlet filter instead? Did you run into any major issues? [1] http://www.nabble.com/NavigationHandler-%2B-Security-tf2081383.html#a5745371 [2] http://www.nabble.com/obtaining-%22real%22-url-after-navigation-rules-tf692306.html#a1827241 Regards, Jeff Bischoff Kenneth L Kurz & Associates, Inc. Andrew Robinson wrote: > For my company, I wrote our own custom servlet filter for security. We > did not want to introduce Spring into the framework so that ruled out > acegi. Container managed security in J2EE is a horrible specification > and does not fit well with JSF at all (not enough ways to customize it > and it only works on URLs, not view IDs). > > I'd like to see Sun address security for J2EE that is JDK 1.5 enhanced > (annotation support in JSF backing beans for example) and is designed > for JSF compatibility. > > On 11/3/06, Jeff Bischoff <[EMAIL PROTECTED]> wrote: >> Greetings Colleagues, >> >> I have often wondered what the majority of you are using for >> authentication and authorization in your non-public websites. Over the >> last year on this mailing list, I have seen bits and scraps of >> discussion on this topic. Most often, I hear mention of solutions like >> container-managed security and phase listeners. Sometimes custom >> navigation-handlers or servlet filters get mentioned too. Cant' say I've >> quite seen evidence of any consensus on which of these is preferred, so >> I'm interested to hear your thoughts. >> >> I have come across this article [1] which offers an approach (and some >> source code) to authorization in JSF. What are your opinions on this >> approach? Would you consider this and similar approaches to be best >> practice? What other alternatives can you recommend (from experience)? >> >> I will post my specific requirements for my security search as a reply >> to this post, so as not to narrow the overall discussion. >> >> [1] http://java.sys-con.com/read/250254_1.htm >> >> Regards, >> >> Jeff Bischoff >> Kenneth L Kurz & Associates, Inc. >> >> >> > > >
