The JBoss SSO is useful to authenticate a user on one GateIn Portal node in a cluster and have that authentication automatically carry across to other nodes in the cluster.
This authentication can also be used in any other web applications which may require authentication, provided that these applications use same roles as the main portal instance. Attempting to use an SSO authentication in an application that uses different roles may create authorization errors (403 errors, for example).
This behavior is coming from the fact that the same JAAS principal is added by the SSO valve to all HTTP requests, even to other web applications. So the same roles are required because of it. There is alternative that you can configure SSO valve with the parameter reauthenticate="true", which will force SSO valve to perform reauthentication with saved credentials in each HTTP request against security domain of particular web application where the request is coming. This will enforce that new principal for that web application will be created with updated roles for that web application. In other words, when requireReauthentication is false (default state), you need to have same roles among web applications. When requireReauthentication is true, you need to have the same username and passwords.
Default configuration
In file GATEIN_HOME/standalone/configuration/standalone-ha.xml you can see that SSO is enabled by default as there is this line in configuration of JBoss web subsystem:
<sso cache-container="web" cache-name="sso" reauthenticate="false" />
This means that you don't need to do nothing if you access two GateIn Portal servers via loadbalancer as you're using same URL for access servers (which is actually URL of Apache loadbalancer). In this case you have automatic SSO when one node fail and loadbalancer needs to redirect client request to second node (sticky session).
Clustered SSO in shared DNS domain
This scenario is helpful if you're not using loadbalancer, but you directly access different GateIn Portal servers in different URLs on same DNS domain. In this example, we will use two GateIn Portal servers. First will be running on host machine1.yourdomain.com and second on host machine2.yourdomain.com .
-
If you are on Linux, you can configure the /etc/hosts file which contains these lines. This will allow you to test the scenario with two GateIn Portal servers on one physical machine:
192.168.2.7 machine1.yourdomain.com
10.11.45.78 machine2.yourdomain.com
-
Let's configure your domain via attribute domain of sso configuration in file GATEIN_HOME/standalone/configuration/standalone-ha.xml
<sso cache-container="web" cache-name="sso" reauthenticate="false" domain="yourdomain.com" />
This needs to be configured on both servers. This configuration means that cookie JSESSIONIDSSO will be scoped to particular domain yourdomain.com (by default it's scoped only to host where authentication happened)
-
You need to configure same datasource on both servers to ensure that both servers will share same database (shared database is general requirement for cluster setup). You can look to chapter Database Configuration to see some general info about datasource setup. Note that you need to configure it in file standalone-ha.xml instead of standalone.xml because you are using clustered setup. By default, standalone-ha.xml is configured to use shared H2 database, which is intended to be used only for testing purpose.
-
Run first server with command:
./standalone.sh -b machine1.yourdomain.com -c standalone-ha.xml -Djboss.node.name=node1
-
Run second server with command:
./standalone.sh -b machine2.yourdomain.com -c standalone-ha.xml -Djboss.node.name=node2
-
Go to http://machine1.yourdomain.com:8080/portal and log in as a user john. Then go to http://machine2.yourdomain.com:8080/portal and you will see that you're logged here as john as well. Let's logout on one node and you will be logged from second node as well.