Bug 793536 (JBEPP-615)

Link: Added: This issue related GTNPORTAL-1641

The reason this does not work is because "node1.local.network" and "node2.local.network" are logically separate portals. A session established on node1 has nothing to do with a session established on node2.

Keeping this in mind which how it should be, there is no session replication between the two nodes which includes authenticated session.

The SSO cookie from the ClusteredJBossSSO valve does not replicate session state. It only keeps a shared cache of authentication credentials. The GateIn authentication process relies on several handshakes that are session oriented. This is not a problem. This is by design for better security.

You can verify this by swapping out the GateIn authentication stack with the simple authentication stack of jmx-console using:

<!--
	<login-config>
	  <auth-method>FORM</auth-method>
	  <realm-name>gatein-domain</realm-name>
		<form-login-config>
		  <form-login-page>/initiatelogin</form-login-page>
			<form-error-page>/errorlogin</form-error-page>
	  </form-login-config>
	</login-config>
	<security-role>
	  <description>a simple user role</description>
	  <role-name>users</role-name>
	</security-role>
	<security-role>
	  <description>the admin role</description> 
	  <role-name>admin</role-name>
	</security-role>
	-->
	<login-config>
	  <auth-method>BASIC</auth-method>
	  <realm-name>JBoss JMX Console</realm-name>
	</login-config>

	<security-role>
	  <role-name>JBossAdmin</role-name>
	</security-role>

in the 02portal.war/WEB-INF/web.xml and you will notice that ClusteredSSO is able to establish an authenticated session.

Based on this, this is not a bug. I will leave the issue open for now so that we are on the same page.

btw- This would be a bug, if node1.local.network and node2.local.network were logically the same portal hidden behind a load balancer. I am not sure if this usecase has been tested

Closing, as discussed with Marek

Thanks for your feedback Sohil.

For completion, I've tried your configuration and it works. It's sufficient to change auth-method from FORM to BASIC to have it working.

Today I've tried some more testing and debugging to understand more deeply why FORM is not working and BASIC is working. And fact is that with BASIC is call to InitiateLoginServlet avoided as described by Sohil in call yesterday. And so the difference is:

- jaas credentials with BASIC authentication are username "root" and password "gtn" . And these credentials works for both node1 and node2 and so SSO valve works.
- jaas credentials with FORM authentication are username "root" and password "rememberme-445464..." . And this works only on node1 because that token can't be found on TokenStore on node2. 

So I am seeing that there is possibility to have it working with FORM authentication by one of these two ways:

Way 1) Change 3 lines in login.jsp on both nodes to use JAAS directly and avoid TokenService mechanism:

- <form name="loginForm" action="<%= contextPath + "/login"%>" method="post" style="margin: 0px;">
+ <form name="loginForm" action="<%= contextPath + "/private/j_security_check"%>" method="post" style="margin: 0px;">


- <td><input class="UserName" name="username" value="<%=username%>"/></td>
+ <td><input class="UserName" name="j_username" value="<%=username%>"/></td>

- <td><input class="Password" type="password" name="password" value=""/></td>
+ <td><input class="Password" type="password" name="j_password" value=""/></td>

SSO valve *WORKS* for me with this simple change. With this change login workflow is same as with BASIC authentication.

Way 2) Implement some replication of TokenService so that rememberme tokens from node1 can be found on node2 as well. Now TransienTokenStore is using simple ConcurrentMap for storing tokens so the tokens can be found only in the same JVM and so tokens from node1 can't be found on node2. Possible issue is that I am not sure about security when tokens with passwords are replicated from one node to another node.

But at least we have workaround for customers or people who are really interested in clustered SSO valve.