ICEfaces Forums

hello everybody,

we use acegi-security (http://acegisecurity.org/) in an application that we migrated from facelets to icefaces recently. acegi provides methods that respond to the component-properties "renderedOnUserRole" and "enabledOnUserRole". In a first try acegi seems to work fine with icefaces - these two integrated seamlessly.

But getting a bit deeper into icefaces we encountered a strange problem in combination of the security-related tasks and the IntervalRenderer. We added a clock to our app to display the current date and time and to keep the connection alive (which used to get lost accidentially). With the clock being displayed we have the problem, that all our components with the property "renderedOnUserRole" will disappear at the IntervalRenderer intervals. *Any* request coming from the client itself(including partialSubmits) restores those components again until the next IntervalRenderer interval will remove them once again.

Is there anything we have to consider when using the IntervalRenderer AND "renderedOnUserRole"?

The IntervalRenderer makes use of a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check (the check is possible on the first rendering pass because the original ServletRequest is used then.)

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server (integration with acegi-security is likely preferable as it will be more portable). This will be addressed in an upcoming release.

Thank you Ted, that's what we already supposed. So we'll be patiently waiting until the very release and hope that our users will have their own watch, so they won't need the app's clock... ;-)

CITE:
The IntervalRenderer makes use of a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check...

Is the same true for the OnDemandRenderer?
And...when do you expect to have a corrected release ready for publication?

Thanks in advance!
Thomas

PS: your support is excellent!

The acegi security API seemed to provide exactly what we needed (role checking directly from a Principal) so the implementation went very smoothly. (Please keep in mind that this is very preliminary integration and further work is undoubtedly required. Our testing, though, shows that acegi security provides a persistent security context that works with application initiated rendering.)

Thanks for your interest; ICEfaces will continue to strive for the speed and reliability of german trains ...

Wow, that fast! Where does the name ICEfaces come from? might very well be the german high-speed-train (called "ICE")!

Thanks a lot
Christian

Initial integration with acegi security has been added to ICEfaces and will be available in the next release. This feature will be of an "early access" nature, so we will be looking for your feedback.

One important consideration will be that since ICEfaces needs access directly to the acegi security APIs, acegi-security-1.0.1.jar cannot be installed in server/lib, it must be installed in common/lib (this is for tomcat, other application servers will require their own installation adjustments).

My collegue Christian is on holidays. Just wanted to tell you that ACEGI seems to work smoothly with IceFaces 1.0.1.

Thank you very much!
Thomas

Thomas: Would you please provide your insight on how to even get started using acegi-security with ICEfaces?

*I am really stuck right now.*

Thanks,

--Todd

Christian:

OK, I've been going through a lot of documentation linked from:

http://www.acegisecurity.org/articles.html

From what I can find, the following statement caught my eye:

The issues I encountered are all related to the authentication mechanism - all other configurations work just fine if done as described in the Acegi manual (please please take great care in observing the servlet filter order or else no donut for you).

So, your not the only one dealing with issues.

IMO: This is not a ICEfaces issues - more a JSF issue.

Still hammering away on this.

Thanks,

--Todd

Hi Todd,

just found your other acegi-thread in this forum.

To be honest, my integration of ICEfaces and acegi works only a little bit. Up to now i'm able to secure URLs reliably and to display components depending on the user role - as long as i use "normal", client initiated requests only.

One other thing that's working is MethodSecurity using the SecurityInterceptor. But I do *not* use the acegi-security api directly.

What I did do to get started was to put all the acegi jars i could grab on my /lib dir, including the tiger one (might be important for Java 5 ...?), adjusted the acegi configuration with the proper file names and user roles (using the inMemoryDao for simplicity-reasons) and added the filter entry and bean-definition in my web.xml. That's all that was needed to make the URL-Security work.

As the rest doesn't work really well i better won't try to advice you, my hints might prove worthless or even harmful .. :-( Unfortunately i discovered my problems only a few minutes ago, otherwise i wouldn't have tried to offer help on a topic that i apparently do not really understand myself - sorry for that. I'll let you know if i find a solution.

Greetz
Christian

Christian: Thank you.

I went out to http://home.hccnet.nl/bart.van.riel/spring_acegi_tutorial.html

and read through the tutorial, I was unable to load the .war in Sun Java System Application Server 8.2 and I couldn't find the .zip containing the source.

I have the following jars added to my /lib directory for Sun Java System Application Server 8.2:

acegi-security-1.0.1.jar
acegi-jsf-1.1.2.jar

What is acegi-security-tiger-1.0.1.jar, I've searched on the Spring forum and googled without a lot of success. The readme.txt doesn't help either.

What I am stuck at is actual useful examples of Bean code using the acegi-secruity api.

How do I even get started?

All of the information I've looked at just reviews setting up the web.xml and acegi.xml as you've provided.

By the way: Thanks for attaching those.

Anyways, I am searching for as much "getting started information as I can".

Thanks,

--Todd

Hello Ted,

i just tried to use the "renderedOnUserRole" in combination with the IntervalRenderer using ICEfaces 1.0.1 and acegi 1.0.1, but my problem remains: some components are being displayed correctly but the most of them are killed by the IntervalRenderer. Maybe the problem is that Tomcat cannot find the acegi- and spring-jars that i put in common/lib. Is there anything i have to do so that the application *does* use the jars in that directory?

Hi Todd,

as my collegue Thomas is on holidays i'll try to answer your question. First of all i'd like to recommend a Spring Acegi Tutorial (just in case haven't found it already: http://home.hccnet.nl/bart.van.riel/spring_acegi_tutorial.html)
It provides a good introduction and overview to acegi.

We use Spring 1.2.5 and acegi 1.0.1. From acegi you'll need acegi-security-1.0.1.jar and eventually acegi-security-tiger-1.0.1.jar. Additionally you'll need acegi-jsf-1.1.2.jar (avaliable via http://sourceforge.net/project/showfiles.php?group_id=137466).
And of course you need ICEfaces 1.0.1.

I'll attach the relevant parts of our web.xml and acegi.xml (and put in some english comments). That's all!

To provide you with better hints i'd need to know *where* you're stuck exactly and to see your configuration.

Hope i could help you a bit
Christian

I am so close to getting AuthenticationProcessingFilter to work it's not funny.

The issue is, need for specific username and password field names.

They need to be:

<ice:inputText
id="j_username"
size="8"
maxlength="8"
required="true">
<f:validateLength maximum="8" minimum="3"/>
</ice:inputText>

<ice:inputSecret
id="j_password"
size="8"
maxlength="8"
required="true">
<f:validateLength maximum="8" minimum="3"/>
</ice:inputSecret>

However, the parsed HTML names are:

<INPUT class="iceInputtext" id="_id2:j_username" maxlength="8" name="_id2:j_username" onblur="javascript:setFocus('');" onfocus="javascript:setFocus(this.id);" onkeypress="javascript:iceSubmit(form,this,event);" size="8" style="" type="text" value="">
</INPUT>

<INPUT class="iceInputtext" id="_id2:j_password" maxlength="8" name="_id2:j_password" onblur="javascript:setFocus('');" onfocus="javascript:setFocus(this.id);" onkeypress="javascript:iceSubmit(form,this,event);" size="8" style="" type="password" value="">
</INPUT>

Thus, I cannot get AuthenticationProcessingFilter to work in the chain.

MyFaces (cring) has a property called forceID, which you can set to a boolean - which solves the issue of having specific field names.

<pulling-hair>Aaaahhhh!</pulling-hair>

Thanks,

--Todd

acegi-security log:

13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:192 - Request is to process authentication
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:192 - Request is to process authentication
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:192 - Request is to process authentication
13:05:00,676 WARN LoggerListener,httpWorkerThread-8080-2:55 - Authentication event AuthenticationFailureBadCredentialsEvent: ; details: org.acegisecurity.ui.WebAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: 13014621224effffffffffef23436b7be8632; exception: Bad credentials
13:05:00,676 WARN LoggerListener,httpWorkerThread-8080-2:55 - Authentication event AuthenticationFailureBadCredentialsEvent: ; details: org.acegisecurity.ui.WebAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: 13014621224effffffffffef23436b7be8632; exception: Bad credentials
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:413 - Updated SecurityContextHolder to contain null Authentication
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:413 - Updated SecurityContextHolder to contain null Authentication
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:413 - Updated SecurityContextHolder to contain null Authentication
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:419 - Authentication request failed: org.acegisecurity.BadCredentialsException: Bad credentials
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:419 - Authentication request failed: org.acegisecurity.BadCredentialsException: Bad credentials
13:05:00,676 DEBUG AuthenticationProcessingFilter,httpWorkerThread-8080-2:419 - Authentication request failed: org.acegisecurity.BadCredentialsException: Bad credentials
13:11:01,282 DEBUG HttpSessionEventPublisher,ContainerBackgroundProcessor[StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/login]]:113 - Publishing event: org.acegisecurity.ui.session.HttpSessionDestroyedEvent[source=org.apache.catalina.session.StandardSessionFacade@17067ba]
13:11:01,282 DEBUG HttpSessionEventPublisher,ContainerBackgroundProcessor[StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/login]]:113 - Publishing event: org.acegisecurity.ui.session.HttpSessionDestroyedEvent[source=org.apache.catalina.session.StandardSessionFacade@17067ba]
13:11:01,282 DEBUG HttpSessionEventPublisher,ContainerBackgroundProcessor[StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/login]]:113 - Publishing event: org.acegisecurity.ui.session.HttpSessionDestroyedEvent[source=org.apache.catalina.session.StandardSessionFacade@17067ba]