Re: spring security/acegi and myFaces orchestra conversation scope
Hi Mario Your use case is pretty sophisticated. I don't think, this use case is so sophisticated. Thinking about ajax applications, running multiple instances of the application in different browser windows. When loging on, it is nice, because you only have to do this, when stating the first instance of the application. Everything works fine so far. The problem occurs, when login off. As soon as you log off out of the first instances of the applications, all instances loos their (security)context, resulting in broken ajax communication! Pretty messy to capture and solve properly :-) best regards Matthias Gerber
spring security/acegi and myFaces orchestra conversation scope
Hello We have a web application, using ACEGI-Security (new known as Spring Security). Lately we added MyFaces Orchestra form handling conversation scope, providing different application states in different browser windows on the same client. It works great, but there is some issue according security. When ACEGI-Security is used with org.acegisecurity.context.HttpSessionContextIntegrationFilter, authenticated principles are stored in the session context, using a SecurityContext instance. When working with conversation scope, we would like to authenticate users for one conversation only, not for the whole session. We tried this, implementing a filter using a conversation scope bean to store the SecurityContext in. So far it did not work, because of the sequence, the Filters are called. Changing this sequence gets pretty messy because security has to be applied for all ressources of the application, and the conversation scope is only part of the javax.faces.webapp.FacesServlet. So the good way to goo, is to ensure security first, before calling any other servlet/filter, isn't it? Is there a proper way to integrate spring security on an conversation scope, provided by orchestra, so that one can login for each conversation separately? best regards Matthias Gerber
spring security/acegi and myFaces orchestra conversation scope
Hello We have a web application, using ACEGI-Security (new known as Spring Security). Lately we added MyFaces Orchestra form handling conversation scope, providing different application states in different browser windows on the same client. It works great, but there is some issue according security. When ACEGI-Security is used with org.acegisecurity.context.HttpSessionContextIntegrationFilter, authenticated principles are stored in the session context, using a SecurityContext instance. When working with conversation scope, we would like to authenticate users for one conversation only, not for the whole session. We tried this, implementing a filter using a conversation scope bean to store the SecurityContext in. So far it did not work, because of the sequence, the Filters are called. Changing this sequence gets pretty messy because security has to be applied for all ressources of the application, and the conversation scope is only part of the javax.faces.webapp.FacesServlet. So the good way to goo, is to ensure security first, before calling any other servlet/filter, isn't it? Is there a proper way to integrate spring security on an conversation scope, provided by orchestra, so that one can login for each conversation separately? best regards Matthias Gerber
Re: spring security/acegi and myFaces orchestra conversation scope
Hi! Is there a proper way to integrate spring security on an conversation scope, provided by orchestra, so that one can login for each conversation separately? Phu, we too use Spring Security, but to authenticate against the whole session. First, I think you meant you would like to authenticate against a conversation context, no? The conversation context is the one responsible to do the window separation and to hold multiple conversations. Your use case is pretty sophisticated. Unhappily I have no clue if it can work at all. You have to find a way to let Spring Security get/fetch the principal from the conversation context. Are you using form authentication? Else you might run into problems where the browser sends already known user credentials to any login request. Probably, best will be you implement your own security layer :-( Ciao, Mario
