XTAM Federated Sign-In Module – Timeout, Connection Forbidden or 403 Errors
After deploying the XTAM Federated Sign-In module (FSM), you may receive generic Timeout or 403 errors in your browser or log files if it was not properly configured.
We assume that after adding the FSM you can login to it successfully but then the XTAM page does not appear. Instead, these generic exceptions appear in the log or in your browser.
After authentication by the FSM it generates a ticket and redirects the browser to the XTAM WEB Application. The WEB Application then takes this ticket and validates it with the same FSM before generating the page. To accomplish this the XTAM WEB Application, from the computer it is installed, connects to a URL at https://company.com/cas (with the ticket to validate and its own URL as parameter). The error indicates that this call fails. The important event here is that it is not the browser from your workstation that makes this call but XTAM WEB app from the computer where XTAM is installed.
First, to validate tickets with the FSM, XTAM should know it’s a load balancer URL. This value is defined using the following parameters in the $XTAM_HOME/web/conf/catalina.properties file:
cas.managed.path=https://company.com cas.server.name=https://company.com cas.server.prefix=https://company.com/cas
Check these parameters to ensure they are accurate for your deployment. If they are not, please modify them as required and when finished, save the file then restart the PamManagement (Windows) or pammanager (Linux/Unix) service to complete the configuration.
Based on our experience with other users, we have found that configurations that may cause this behavior are the following:
- DNS on the XTAM computer works differently and does not resolve cas.managed.path to the computer where the load balancer resides. For example, there is a host record making it a localhost. We recommend pinging the load balancer to see how it resolves.
- Routing behind the load balancer is configured in such a manner that it does not route traffic from inside the farm to the load balancer front end. For example, it short cuts it back to the localhost again to a non-SSL connection or the traffic from inside the farm comes to the wrong interface of the server with reversed proxy where the load balancer does not listen.
- The load balancer does not process requests that came from inside the farm in the right way like it processes requests from the outside.