myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Medina <>
Subject Re: Acegi and JSF integration
Date Fri, 01 Jul 2005 08:49:05 GMT
Hi Richard,

I'm currently using Acegi and JSF together and I found a feasible
solution (at least to me) to solve the gap between them.

The main problem comes from the fact that Acegi uses a filter to do
the security stuff, and also Acegi expects some information from the
request, that cannot be given by JSF without some modifications (or
maybe some hacks).

The first problem comes with Acegi expecting a specific parameter name
for the user and password in the form. As JSF generates the IDs for
the form elements, you will have to use MyFaces "forceId" property in
order to ensure that the expected IDs arrive to the Acegi filter.

Regarding the filter, I also had to extend it in order to provide
extra functionality so as to be able to check not only the user and
the password, but also some other parameters (like the IP used to
connect to the web site).

So, if you use the "forceId" attribute, and then use a "commandButton"
with an action in one of your JSF beans, what will happen?:

1) The JSF page gets rendered within the JSF context.
2) Expected IDs are given to the form elements (user & password, for example)
3) When the login information is entered, a new request is created and
the Acegi filter catches it
4) The Acegi filter tries to take from the request parameter map all
the expected information, and it can, due to the fact of using
5) Acegi executes its stuff without knowing it is in a JSF context and:
    5.1) If Acegi can validate the user, then it will redirect the
request, not to the JSF bean specified in the form, but to the home
page specified in the Spring's application context XML file (see Acegi
declarative configuration),
    5.2) If Acegi cannot validate the user, then here comes a little
hack. We have to make Acegi return the flow to the JSF context, in
particular to the JSF bean action method specified for the web form.
What I've done is to save the Acegi exception in the session, then
just continue the filter chain, and when the flow arrives to my JSF
action method, take the exception from the session, compose a JSF
error message, and return a NULL from the action method in order to
stay in the same page. So the final result is that the login page gets
redrawn, and an error message appears to the user (using h:message

I hope this can help you.


2005/7/1, Richard Wallace <>:
> Hey everyone,
> I'm progressing with our move to Java and JSF and am trying to integrate
> some security.  I've decided on using Acegi Security because I need to
> be able to have domain object level ACLs and it's the most complete open
> source implementation I've seen.  But, I'm having some problems figuring
> how best to integrate it with JSF.
> The main issue is that most of the servlet security stuff is implemented
> in Servlet Filters, including the part that authenticates the user.
> Whats worse, IMO, is that the Filters are actually Spring managed beans
> proxied by a delegating Filter.  The main problems I have with this is
> that I can't create a nice JSF form with an
> action="#{authHandler.authenticate}" action handler.  I'd also like to
> control the flow of the page and what happens when logins succeed/fail
> from the JSF navigation.  As it stands now that's actually handled by
> one of the Spring managed beans.
> To these ends I've created an AuthenticationHandler backing bean, mostly
> just copying the code in the AuthenticationProcessingFilter class which
> listens for requests to a certain URL and tries to login the user with
> the credentials in the request.  The other stuff is a bit more
> complicated and I'm not 100% sure where to begin.  I'm thinking I need
> to create PhaseListener classes for the other Filters and copying the
> code from the corresponding filters.
> Has anyone worked on integrating Acegi  and JSF more seemlessly before?
> I'd appreciate any advice anyone can give.
> Thanks,
> Rich

View raw message