Shiro using Tomcat Session Management with Tomcat Clustering

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Shiro using Tomcat Session Management with Tomcat Clustering

jim.piersol@gmail.com
Got a problem I cannot chase down, and need help. Hoping Les or Brian can set
me straight.

I have a web application configured using Shiro 1.4.0 with Form
Authentication.

I have a custom Realm to get Auth info from DB.

I am using native Tomcat session management.  We have a Tomcat cluster, i.e.
2 or 3, tomcat nodes configured to use SimpleTCPCluster to allow session
replication across the tomcat nodes, per basic Tomcat Clustering setup.  We
front this with Apache mod_proxy for load balancing, but this problem
presents even when hitting Tomcat1 node directly.

If I only have one Tomcat node running, everything works perfectly.  Users
can login on first attempt with no issues.

When I have a second, virtually identical, Tomcat node started, things get
strange.  To the layman, the first login attempt always fails, but the
second attempt will always work.

What I see in reality is the first attempt initially works, but then once
authentication is successful, then next request triggers another 302 back to
the login page.  This is very consistent.

I have chased and chased via debugger, but cannot seem to put my finger on
it.  I believe the issue is coming from the SecurityUtils.getSubject() code.  
I am not sure why, but it seems like I am not getting the Authenticated
Subject back all the time.  Its like the ThreadState does not have the right
Subject attached to it.

Its a long shot, but just looking for a clue on what might be happening.  

Here is my shiro.ini

#
=============================================================================
# Shiro INI configuration
#
#
=============================================================================

#-----------
# Main
# ----------
[main]

authc = my.auth.VerboseFormAuthenticationFilter
authc.failureKeyAttribute=simpleShiroApplicationLoginFailure

authc.loginUrl = /pre-auth/authentication/login.html
authc.successUrl = /index.html
logout.redirectUrl = /pre-auth/authentication/login.html

vRealm = my.auth.VnfMgrCustomRealm
securityManager.realms = $vnfmgrRealm

credentialsMatcher =
org.apache.shiro.authc.credential.Sha256CredentialsMatcher
credentialsMatcher.storedCredentialsHexEncoded = false
credentialsMatcher.hashIterations = 1024
vnfmgrRealm.credentialsMatcher = $credentialsMatcher

#
-----------------------------------------------------------------------------
# URLS - followed by Filter Chains.
#
-----------------------------------------------------------------------------
[urls]
/v1/abc/** = anon
/v1/gnfs/** = anon
/logout = logout
/pre-auth/welcome/** = anon
/pre-auth/authentication/img/favicon/favicon.ico = anon
/pre-auth/authentication/ajax/** = anon
/pre-auth/authentication/css/** = anon
/pre-auth/authentication/data/** = anon
/pre-auth/authentication/design-resources/** = anon
/pre-auth/authentication/fonts/** = anon
/pre-auth/authentication/img/** = anon
/pre-auth/authentication/js/** = anon
/pre-auth/authentication/php/** = anon
/pre-auth/authentication/sound/** = anon
/pre-auth/authentication/xml/** = anon
/v1/vim/heartbeat/heartbeat/** = anon
/v1/vim/heartbeat/register/** = anon
/** = authc

Any suggestions on a better way to track this down would be appreciated.



--
Sent from: http://shiro-user.582556.n2.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Shiro using Tomcat Session Management with Tomcat Clustering

Brian Demers
Are you sure the tomcat session clustering is working? You may want to test that out independently.

-Brian

> On Feb 21, 2018, at 4:04 PM, "[hidden email]" <[hidden email]> wrote:
>
> Got a problem I cannot chase down, and need help. Hoping Les or Brian can set
> me straight.
>
> I have a web application configured using Shiro 1.4.0 with Form
> Authentication.
>
> I have a custom Realm to get Auth info from DB.
>
> I am using native Tomcat session management.  We have a Tomcat cluster, i.e.
> 2 or 3, tomcat nodes configured to use SimpleTCPCluster to allow session
> replication across the tomcat nodes, per basic Tomcat Clustering setup.  We
> front this with Apache mod_proxy for load balancing, but this problem
> presents even when hitting Tomcat1 node directly.
>
> If I only have one Tomcat node running, everything works perfectly.  Users
> can login on first attempt with no issues.
>
> When I have a second, virtually identical, Tomcat node started, things get
> strange.  To the layman, the first login attempt always fails, but the
> second attempt will always work.
>
> What I see in reality is the first attempt initially works, but then once
> authentication is successful, then next request triggers another 302 back to
> the login page.  This is very consistent.
>
> I have chased and chased via debugger, but cannot seem to put my finger on
> it.  I believe the issue is coming from the SecurityUtils.getSubject() code.  
> I am not sure why, but it seems like I am not getting the Authenticated
> Subject back all the time.  Its like the ThreadState does not have the right
> Subject attached to it.
>
> Its a long shot, but just looking for a clue on what might be happening.  
>
> Here is my shiro.ini
>
> #
> =============================================================================
> # Shiro INI configuration
> #
> #
> =============================================================================
>
> #-----------
> # Main
> # ----------
> [main]
>
> authc = my.auth.VerboseFormAuthenticationFilter
> authc.failureKeyAttribute=simpleShiroApplicationLoginFailure
>
> authc.loginUrl = /pre-auth/authentication/login.html
> authc.successUrl = /index.html
> logout.redirectUrl = /pre-auth/authentication/login.html
>
> vRealm = my.auth.VnfMgrCustomRealm
> securityManager.realms = $vnfmgrRealm
>
> credentialsMatcher =
> org.apache.shiro.authc.credential.Sha256CredentialsMatcher
> credentialsMatcher.storedCredentialsHexEncoded = false
> credentialsMatcher.hashIterations = 1024
> vnfmgrRealm.credentialsMatcher = $credentialsMatcher
>
> #
> -----------------------------------------------------------------------------
> # URLS - followed by Filter Chains.
> #
> -----------------------------------------------------------------------------
> [urls]
> /v1/abc/** = anon
> /v1/gnfs/** = anon
> /logout = logout
> /pre-auth/welcome/** = anon
> /pre-auth/authentication/img/favicon/favicon.ico = anon
> /pre-auth/authentication/ajax/** = anon
> /pre-auth/authentication/css/** = anon
> /pre-auth/authentication/data/** = anon
> /pre-auth/authentication/design-resources/** = anon
> /pre-auth/authentication/fonts/** = anon
> /pre-auth/authentication/img/** = anon
> /pre-auth/authentication/js/** = anon
> /pre-auth/authentication/php/** = anon
> /pre-auth/authentication/sound/** = anon
> /pre-auth/authentication/xml/** = anon
> /v1/vim/heartbeat/heartbeat/** = anon
> /v1/vim/heartbeat/register/** = anon
> /** = authc
>
> Any suggestions on a better way to track this down would be appreciated.
>
>
>
> --
> Sent from: http://shiro-user.582556.n2.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Shiro using Tomcat Session Management with Tomcat Clustering

sreenivas harshith
In reply to this post by jim.piersol@gmail.com
Hi jim,

I had the same thread state issue security utils get subject was not getting the correct subject every time. I was using tomee with http nio. I was trying to resolve the subject using session ID but I was getting different subjects randomly unrelated to session ID you can check the below URL

The only way I could fix was using a subject builder and passing the session ID to the same and resolve the subject. Looks to me this might resolve your issue as well. Let me know if it works.

Thanks,
Sreenivas.

On Thu, Feb 22, 2018 at 2:34 AM, [hidden email]
Got a problem I cannot chase down, and need help. Hoping Les or Brian can set
me straight.

I have a web application configured using Shiro 1.4.0 with Form
Authentication.

I have a custom Realm to get Auth info from DB.

I am using native Tomcat session management.  We have a Tomcat cluster, i.e.
2 or 3, tomcat nodes configured to use SimpleTCPCluster to allow session
replication across the tomcat nodes, per basic Tomcat Clustering setup.  We
front this with Apache mod_proxy for load balancing, but this problem
presents even when hitting Tomcat1 node directly.

If I only have one Tomcat node running, everything works perfectly.  Users
can login on first attempt with no issues.

When I have a second, virtually identical, Tomcat node started, things get
strange.  To the layman, the first login attempt always fails, but the
second attempt will always work.

What I see in reality is the first attempt initially works, but then once
authentication is successful, then next request triggers another 302 back to
the login page.  This is very consistent.

I have chased and chased via debugger, but cannot seem to put my finger on
it.  I believe the issue is coming from the SecurityUtils.getSubject() code. 
I am not sure why, but it seems like I am not getting the Authenticated
Subject back all the time.  Its like the ThreadState does not have the right
Subject attached to it.

Its a long shot, but just looking for a clue on what might be happening. 

Here is my shiro.ini

#
=============================================================================
# Shiro INI configuration
#
#
=============================================================================

#-----------
# Main
# ----------
[main]

authc = my.auth.VerboseFormAuthenticationFilter
authc.failureKeyAttribute=simpleShiroApplicationLoginFailure

authc.loginUrl = /pre-auth/authentication/login.html
authc.successUrl = /index.html
logout.redirectUrl = /pre-auth/authentication/login.html

vRealm = my.auth.VnfMgrCustomRealm
securityManager.realms = $vnfmgrRealm

credentialsMatcher =
org.apache.shiro.authc.credential.Sha256CredentialsMatcher
credentialsMatcher.storedCredentialsHexEncoded = false
credentialsMatcher.hashIterations = 1024
vnfmgrRealm.credentialsMatcher = $credentialsMatcher

#
-----------------------------------------------------------------------------
# URLS - followed by Filter Chains.
#
-----------------------------------------------------------------------------
[urls]
/v1/abc/** = anon
/v1/gnfs/** = anon
/logout = logout
/pre-auth/welcome/** = anon
/pre-auth/authentication/img/favicon/favicon.ico = anon
/pre-auth/authentication/ajax/** = anon
/pre-auth/authentication/css/** = anon
/pre-auth/authentication/data/** = anon
/pre-auth/authentication/design-resources/** = anon
/pre-auth/authentication/fonts/** = anon
/pre-auth/authentication/img/** = anon
/pre-auth/authentication/js/** = anon
/pre-auth/authentication/php/** = anon
/pre-auth/authentication/sound/** = anon
/pre-auth/authentication/xml/** = anon
/v1/vim/heartbeat/heartbeat/** = anon
/v1/vim/heartbeat/register/** = anon
/** = authc

Any suggestions on a better way to track this down would be appreciated.



--