Andrew,
My responses are inline:
Andrew Robinson wrote:
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.
Aha! That explains it. Well, I'm not much concerned about my static
resources.
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.
>
Sounds like what Dominik is also doing with annotations. Of course you
are right, the model is really what you want to protect, more than the view.
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.
Hmmm. If my main concern is simply to secure JSF views, perhaps I can
get away with just a phase listener? The article I mentioned before
intregated a phase listener with container-managed security. Since I'm
not already using container security, should I just skip that and use
the phase listener standalone? I can see your dislike for this
container-managed security spec. ;)
If you are insterested in my approach of using Seam, check out:
http://docs.jboss.com/seam/latest/reference/en/html/concepts.html#d0e2635
Indeed, I am very interested in using Seam! Unfortunately, my current
project is much too far along at this point. We kept postponing the
decision about page-level authorization because we didn't know which
approach was better.
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.
>>
>>
>>
>
>
>
