You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Richard Wallace <rw...@thewallacepack.net> on 2005/07/01 04:47:48 UTC
Acegi and JSF integration
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
Re: Acegi and JSF integration
Posted by Richard Wallace <rw...@thewallacepack.net>.
I've done much the same, implemented a backing bean that handles
authentication. I took the AuthenticationProcessingFilter out of the
FilterChainProxy. I've got authentication working just fine now, the
only thing left that I have to figure out is if there was a restricted
URL that was requested and caused the user to be redirected to the login
page, how to redirect to that originally requested url rather than let
the JSF navigation rule that handles successful authentication redirect
to the main post-login page. Any suggestions?
Thanks,
Rich
Victor Tatai wrote:
>Hello Richard and Enrique,
>
>I have detailed yet another approach for integranting JSF and Acegi in my blog:
>
>http://www.jroller.com/page/vtatai/20050505#integrating_acegi_with_jsf
>
>Regards,
>
>Victor
>
>On 7/1/05, Enrique Medina <e....@gmail.com> wrote:
>
>
>>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
>>"forceId"
>>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
>>tag).
>>
>>I hope this can help you.
>>
>>Regards.
>>
>>2005/7/1, Richard Wallace <rw...@thewallacepack.net>:
>>
>>
>>>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
>>>
>>>
>>>
>
>
>
>
Re: Acegi and JSF integration
Posted by Victor Tatai <vt...@gmail.com>.
Hello Richard and Enrique,
I have detailed yet another approach for integranting JSF and Acegi in my blog:
http://www.jroller.com/page/vtatai/20050505#integrating_acegi_with_jsf
Regards,
Victor
On 7/1/05, Enrique Medina <e....@gmail.com> wrote:
> 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
> "forceId"
> 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
> tag).
>
> I hope this can help you.
>
> Regards.
>
> 2005/7/1, Richard Wallace <rw...@thewallacepack.net>:
> > 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
> >
>
--
--
"Make things as simple as possible, but no simpler"
-- Albert Einstein
Re: Acegi and JSF integration
Posted by Enrique Medina <e....@gmail.com>.
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
"forceId"
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
tag).
I hope this can help you.
Regards.
2005/7/1, Richard Wallace <rw...@thewallacepack.net>:
> 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
>