Attempting a login page for Acegi using a JSF backing bean

[aberrant80]

Hi, I'm quite new to Acegi but I have gone through the suggested steps and did manage to successfully secure the pages for my web applications using with configuration derived mostly from the samples.

My problem now is that I need to convert the login page into a JSF page, due to some design requirement and some underlying architecture.

I would say that documentation on using alternative login methods for Acegi is quite lacking, but I managed to find:

http://magrokosmos.blogspot.com/2006...h-backing.html

And 2 other blog posts talking about the same thing; that is, to use an actual backing bean to perform manual authentication rather than relying on Acegi's filters.

I have attempted to implement something like that for my own web app but I probably missed something. Now my filterSecurityInterceptor doesn't work anymore and every single page is exposed. The Authentication object seems to disappear in separate requests. Not sure if the post above left something out cos I even tried copying everything exactly.

I would really really appreciate it if someone could take some time to help me break down the necessary steps to move acegi form authentication to backing bean authentication. At least enough so I can start understanding things better.

Thanks for reading. All help appreciated.

[martin.grotzke]

Hi,

i moved with the blog to http://www.javakaffee.de/blog/, the posting you find now at http://www.javakaffee.de/blog/2006/0...-backing-bean/.

What might have been missing is the objectDefinitionSource IS_AUTHENTICATED_FULLY, i added this afterwards as i also found that it was missing.

Can you compare what you have with the one of http://www.javakaffee.de/blog/2006/0...backing-bean/?

This is working for me, so we should manage to get it working for you also

Cheers,
Martin

[aberrant80]

Hmm... after a couple more tweaks I seem to have gotten the filter invocation back working again. Except now firefox is complaining that I have an infinite redirection problem. Funny that I only redirect to login and that page doesn't go anywhere else. But at least all the other pages are trying to forward to login now...

Also, "scope" is not an attribute to the "bean" tag in spring's app context. How did you manage to do that?

EDIT: Never mind about the redirect problem. I accidentally left in an anonymous pattern that kinda redirected the login back to the login because I've already removed the anonymous filter :P

[martin.grotzke]

Sorry if i forgot to mention that i'm using spring2. This is really cool because it introduces new scopes as session or request... This is very useful for integration with JSF and other webframeworks...

[aberrant80]

Is this still possible without using Spring2? Do I have to manually maintain the AuthenticationController at session scope level?

I think I'm not getting something still. Right now, on logout(), SecurityContextHolder.getContext().getAuthenticati on() already returns a null. Is that expected because Acegi already destroyed the Authentication object prior to control reaching logout()? So unless I keep my own session data, I can't actually retrieve the principal from the SecurityContext inside logout() then...

[martin.grotzke]

You should be able to maintain session/request scoped beans with JSF, so define them in the faces-config.xml as managed-beans and inject required properties via the managed-properties mechanism. You should be able to use value expressions that reference spring managed beans when you have configured the DelegatingVariableResolver.

We simply put all beans into the spring configuration file to have a single place where beans are defined...

[jiai]

i moved with the blog to http://www.javakaffee.de/blog/, the posting you find now at http://www.javakaffee.de/blog/2006/0...-backing-bean/.

Thanks to your work, I got it run so far.

But there is another issue: If someone - like me - uses the Creator2/NetbeansVisualWeb programming model, that means not Facelets, she would run into the next problem. Securing on different levels (e.g. secure/extremeSecure) seems to be impossible with Acegi and JSF.
Whilst access for unauthenticated users is prohibited as expected, it seems to me that authenticated/authorized users for "secure" have access to "extremeSecure", even if they are not in the appropriate role.

Did I made a mistake in the filter chain or is it a general problem with JSF and Acegi? There are some articles in this forum which imply the latter.

If it is not an Acegi problem - can somebody please post a working chain for JSF (Creator/NetbeansVisualWeb model) which handles such an escalation of security grades?

jiai

[jiai]

After some more reading in this forum (i.e. http://forum.springframework.org/showthread.php?t=27578), I found out that adding <redirect/> to the navigation case seems to do the job - authorization works now for navigation with JSF.

But I haven't tested what happens if there are parameters within the post - are they possibly evaluated without authorization?
Nevertheless this seems to me as a brittle and awkward solution - isn't there a better, cleaner, Acegi worthly solution with a working filter chain for JSF?

Playing around with acegi-jsf http://www.jroller.com/page/cagatayc...onents_hit_the , the advice to define the "SecurityContextHolderAwareRequestFilter" in the Acegi filter chain was the key to get this taglib (JSF1.2, acegi-jsf v-1-1-2) working.

As a novice user of Spring/Acegi it seems to me, that the out of the box support of JSF from the core Acegi is a bit dissapointing.

Greetings,
jiai

[jiai]

After some more reading in this forum (i.e. http://forum.springframework.org/showthread.php?t=27578), I found out that adding <redirect/> to the navigation case seems to do the job - authorization works now for navigation with JSF.

There is a really bad side effect with this redirect solution: It works only if cookies are enabled! I didn't found a solution to encodeURI for the navigation rule, because it's stored in a static XML file.
There was an article for Webflow which recommends the redirect solution for their framework (http://www.ervacon.com/products/swf/tips/tip4.html) - unfortunately JSF 1.2 seems to be not supported.

So now it's time for me to say: I'm stuck, tired, and hungry ...

Greetings,
jiai

[jiai]

There is a really bad side effect with this redirect solution: It works only if cookies are enabled! I didn't found a solution to encodeURI for the navigation rule, because it's stored in a static XML file.

A short remark on this: This behavior is a bug in JSF1.2_02, according to http://forums.java.net/jive/thread.j...23149&tstart=0. This bug is solved in JSF 1.2_03. Unfortunately Netbeans VisualWeb has a bug in its webuijsf taglibrary which prevents me from upgrading the JSF version. As a workaround I'll enable cookies during development.

Greetings,
jiai