Session distribution with Shiro and EAR

[Iván Gallego]

Hi everyone,

I migrated a few years ago my application packed in an EAR, containing multiple WARs, successfully.

Now I'm trying to be able to distribute the session among the different nodes in the cluster, but when I add the following jboss-all.xml in the META-INF of the EAR, the session stops working even if I'm accessing the same node manually:

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="urn:jboss:1.0">
<shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
<distributable/>
<session-config>
<tracking-mode>COOKIE</tracking-mode>
<cookie-config>
<name>SSOcookie</name>
<path>/</path>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
</shared-session-config>
<distributable-web xmlns="urn:jboss:distributable-web:2.0">
<infinispan-session-management cache-container="web" granularity="SESSION">
<primary-owner-affinity/>
</infinispan-session-management>
</distributable-web>
</jboss>

I've been searching around and found there was some issue with Wildfly 8 with Shiro and people solved it by changing the cookie name, but I guess they weren't trying to distribute the session.

I'm using Wildfly 26.

Any help will be more than welcome!

[Paul Ferraro]

Are the individual web applications in your EAR also <distributable/>?

Can you clarify what exactly you mean by "the session stops working"?

[Iván Gallego]

I removed it since I thought jboss-all would be enough, I'll try to add it again, but it wasn't working before either.

Yeah, sorry... I didn't explain properly, this is what I see from my app logs without any errors in Wildfly logs:

1. I go to the login page and see the cookie with the new session being set.

2. I successfully login. I can see in the logs the user/password is accepted.

3. After a successful login, our app will redirect you to another page. Here I see after debugging the session is empty, so it's assumed there's no user logged in and hence redirected back to the login page

[Iván Gallego]

BTW all the previous steps are going to a single node, so the problem it's not about being distributed. If I remove the cookie name from the jboss-all configuration, then it works correctly for a single node but doesn't get distributed to other nodes

[Paul Ferraro]

On Tuesday, August 30, 2022 at 10:56:26 AM UTC-4 ivan.g...@gmail.com wrote:

BTW all the previous steps are going to a single node, so the problem it's not about being distributed. If I remove the cookie name from the jboss-all configuration, then it works correctly for a single node but doesn't get distributed to other nodes

<distributable/> affects which session manager implementation will be used - so this is definitely relevant.

 

El martes, 30 de agosto de 2022 a las 15:46:27 UTC+1, Iván Gallego escribió:

I removed it since I thought jboss-all would be enough, I'll try to add it again, but it wasn't working before either.

A <distributable/> shared session config requires <distributable/> web applications in order to work correctly.

 

Yeah, sorry... I didn't explain properly, this is what I see from my app logs without any errors in Wildfly logs:

1. I go to the login page and see the cookie with the new session being set.

2. I successfully login. I can see in the logs the user/password is accepted.

3. After a successful login, our app will redirect you to another page. Here I see after debugging the session is empty, so it's assumed there's no user logged in and hence redirected back to the login page

Authentication and HttpSession are orthogonal concerns - and one does not inherently depend on the other.  Can you say more about how your web applications configure authentication?

[Iván Gallego]

I tried adding <distributable/> to all my web.xml but I get the same behaviour.

What in particular would you be looking at in the auth configuration? I see in general is using the regular properties in a shiro.ini, with a couple of overwrites, but don't think that's making much of a difference (this app is more than 10 years old and quite big)

It's using its own implementation of security manager for example (extending DefaultWebSecurityManager from Shiro) and extending EnterpriseCacheSessionDAO with some extra methods, but don't see much of a difference there.

[Iván Gallego]

Could it be related to Shiro being using EhCacheManager instead of Infinispan?

[Paul Ferraro]

On Tue, Aug 30, 2022 at 11:25 AM Iván Gallego <ivan.g...@gmail.com> wrote:
>
> I tried adding <distributable/> to all my web.xml but I get the same behaviour.
>
> What in particular would you be looking at in the auth configuration?

I'm trying to figure out the relationship between the application's
authentication (i.e. how does it indicate that a user is
authenticated) and the HttpSession. Unfortunately, I have no
experience with Shiro.

> I see in general is using the regular properties in a shiro.ini, with a couple of overwrites, but don't think that's making much of a difference (this app is more than 10 years old and quite big)
> It's using its own implementation of security manager for example (extending DefaultWebSecurityManager from Shiro) and extending EnterpriseCacheSessionDAO with some extra methods, but don't see much of a difference there.

Taking a look at
https://github.com/apache/shiro/blob/cd88a85bf1e20f03651983f872044e75b5f6d0e2/core/src/main/java/org/apache/shiro/session/mgt/eis/CachingSessionDAO.java
The framework seems to retain references to the HttpSession outside
the context of the request, which is forbidden by the servlet
specification. This probably explains why the session appears empty
after redirect.
This will be problematic for the default configuration of the
distributed session manager, which is optimized within these
constraints.

To get this to work at all, you will likely need to disable
transactions from the Infinispan cache configuration used by the
distributed session manager.
See: https://docs.wildfly.org/26.1/High_Availability_Guide.html#session_concurrency

> --
> You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/NnW3TWRnQLM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/94a0aa7f-d0ed-4167-8a88-256367722f6cn%40googlegroups.com.

[Paul Ferraro]

This should not matter. Entity caching and HttpSession attribute
caching are independent.

> --
> You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/NnW3TWRnQLM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/107d7ea7-7aa9-43db-8460-71356ed993dan%40googlegroups.com.

[Iván Gallego]

I managed to make it work in a single node disabling transactions! Thanks!

Now from the load balancer, I can see that sends the post to one node, redirects to another and then again redirects to the first node (only using 2 nodes for test purposes) and then the session looks empty again. This is already an improvement because before I was getting logged out after the first redirection, very likely this is something around how my application is handling the session.

I'll give some update if I find what the issue is

Thanks again!

[Iván Gallego]

Forget about the previous message... I was deploying the wrong version of my app and wasted all day debugging it.

After disabling transactions I keep getting the same behaviour if I specify my session cookie name in jboss-all.xml

[Paul Ferraro]

Can you paste your Shiro configuration?
According to https://shiro.apache.org/web.html#session_management you
need to configure Shiro using ServletContainerSessionManager (it
should be the default?), otherwise, it does not look interoperable
with WildFly's session manager.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/7bb9408c-ff01-4d15-a5dc-8ab64d8d7ccen%40googlegroups.com.

[Iván Gallego]

I'm attaching our configuration

We're using an extended version of DefaultWebSessionManager