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
>
>

Reply via email to