Hi Thomas, The JSecurity Developer team doesn't support the Grails plugin directly - although Peter Ledbrook is on our core team, he is the primary author and supporter of the plugin and works on it at his own discretion. So, we don't have a whole lot of knowledge about how it works exactly :) You'd probably find better assistance on the Grails User mailing list.
But, I'll do my best to at least add to the discussion. On Tue, Oct 14, 2008 at 3:53 PM, Thomas Skowronek <[EMAIL PROTECTED]> wrote: > Background information: > Our production environment is comprised of two JBoss 4.0.4.GA servers > running in a cluster. In the embedded Tomcat in JBoss, the > org.apache.catalina.authenticator.SingleSignOn valve has been disabled and > the org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn valve has been > enabled. > > We currently have multiple applications deployed to this cluster using > standard J2EE declarative security via the web.xml file. SSO works for all > applications currently deployed. If a user authenticates in one > application, then they are not required to authenticate in subsequent > applications as long as they have an active session. What does this mean exactly? Is it because their session is clustered/shared across multiple applications? This is how JSecurity works as well, I'm just curious. > Current Project. > We are deploying our first Grails v1.0.3 application to the above mentioned > cluster and have the JSecurity plugin version 0.3-SNAPSHOT installed. > Authentication and authorization are handled by the JSecurity plugin in this > Grails app. > > > Question: > If a user accesses one of the other applications on the cluster, > authenticates, has an active javax.servlet.http.HttpSession and the > java.security.Principal contains the user's username, how do I configure > JSecurity to use that information so the user won't be forced to > authenticate again by JSecurity in the Grails app? JSecurity creates a Subject (aka 'current user') for any request/response pair in the org.jsecurity.web.DefaultWebSecurityManager implementation, specifically the createSubject() method. This method in turn chains to other createSubject overloaded methods, obtaining the data necessary to create the Subject, including the subject's identity and their authentication state. You could subclass the DefaultWebSecurityManager class and override one or more of these overloaded methods (or the methods they call) as you see fit to pull this information in any way you desire. Now, how you tell the Grails plugin to use your SecurityManager subclass implementation, I'm not sure - you'll probably want to ask Peter that on the Grails User list. I hope that helps! Please let me know if you have any other questions! Regards, Les
