You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Thomas Skowronek <ts...@wi.rr.com> on 2008/10/14 21:53:46 UTC
SSO with Grails JSecurity Plugin
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.
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?
I am not really sure where I should put this logic for checking if a user
has already been authenticated by another application or how to get
JSecurity to use it and basically do pass-through authentication. I was
thinking in grails-app/conf/SecurityFilters.groovy.
Testing:
In my SecurityFilters.groovy I have a filter definition that applies to all
controllers.
auth(controller: "*", action: "*") {
before = {
...
In the above filter definition the following returns valid values when a
user authenticates in another application prior to accessing the Grails app.
Example:
request.getUserPrincipal() returns "myTestUserName"
session.getId() returns "9WjpPJQRMcNlYV1Sym5SJA**.phhlt341"
Any direction on how to proceed would be appreciated.
Thank you,
Thomas
RE: SSO with Grails JSecurity Plugin
Posted by Thomas Skowronek <ts...@wi.rr.com>.
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: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
Behalf Of Les Hazlewood
Sent: Wednesday, October 15, 2008 2:16 PM
To: jsecurity-user@incubator.apache.org
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 <ts...@wi.rr.com>
wrote:
> Les,
>
> I appreciate the follow up. I have posted the question on the Grails User
> mailing list.
>
> Thomas
>
> -----Original Message-----
> From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
> Behalf Of Les Hazlewood
> Sent: Wednesday, October 15, 2008 1:18 PM
> To: jsecurity-user@incubator.apache.org
> 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 <ts...@wi.rr.com>
> 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
>
>
Re: SSO with Grails JSecurity Plugin
Posted by Les Hazlewood <lh...@apache.org>.
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 <ts...@wi.rr.com> wrote:
> Les,
>
> I appreciate the follow up. I have posted the question on the Grails User
> mailing list.
>
> Thomas
>
> -----Original Message-----
> From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
> Behalf Of Les Hazlewood
> Sent: Wednesday, October 15, 2008 1:18 PM
> To: jsecurity-user@incubator.apache.org
> 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 <ts...@wi.rr.com>
> 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
>
>
RE: SSO with Grails JSecurity Plugin
Posted by Thomas Skowronek <ts...@wi.rr.com>.
Les,
I appreciate the follow up. I have posted the question on the Grails User
mailing list.
Thomas
-----Original Message-----
From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
Behalf Of Les Hazlewood
Sent: Wednesday, October 15, 2008 1:18 PM
To: jsecurity-user@incubator.apache.org
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 <ts...@wi.rr.com>
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
Re: SSO with Grails JSecurity Plugin
Posted by Les Hazlewood <lh...@apache.org>.
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 <ts...@wi.rr.com> 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