I am bumping this issue since it may have been missed during the weekend. -----Original Message----- From: Thomas Skowronek [mailto:[EMAIL PROTECTED] Sent: Saturday, October 18, 2008 10:26 AM To: '[email protected]' Subject: RE: SSO with Grails JSecurity Plugin
Les, I finally was able to plug in a subclass of DefaultWebSecurityManager, but I still don't understand how to automatically log my user in. http://www.nabble.com/RE%3A-SSO-with-Grails-JSecurity-Plugin-p20035703.html I tried overriding the last createSubject(PrincipalCollection principals, boolean authenticated, Session existing, ServletRequest request, ServletResponse response) in the chain in DefaultWebSecurityManager. In the overridden method, if I try to call HttpServletRequest.getUserPrincipal() to see if there is an existing principle, it throws an exception. http://www.nabble.com/RE%3A-SSO-with-Grails-JSecurity-Plugin-p20038354.html Any help would be appreciated. Regards, Thomas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Les Hazlewood Sent: Wednesday, October 15, 2008 2:16 PM To: [email protected] Subject: Re: SSO with Grails JSecurity Plugin Sounds good. But I think you'll still need to go to the subclassing approach I discussed. That all needs to be done and the last step is just telling Grails how to enable your custom subclass. Regards, Les On Wed, Oct 15, 2008 at 3:01 PM, Thomas Skowronek <[EMAIL PROTECTED]> wrote: > Les, > > I appreciate the follow up. I have posted the question on the Grails User > mailing list. > > Thomas > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Les Hazlewood > Sent: Wednesday, October 15, 2008 1:18 PM > To: [email protected] > Subject: Re: SSO with Grails JSecurity Plugin > > 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 > >
