Crowd SSO not working when using more than one proxy
Crowd SSO breaks when there are two proxies in front of Crowd or any other Atlassian application.
- Enable Crowd SSO: Overview of SSO
- Try logging into Crowd, and then access another Atlassian Application
- SSO does not work, although users can log in to the application manually
- Your proxy or environment is generating a new IP each time a user requests a page
After enabling DEBUG logging from Crowd, the following appears in the atlassian-crowd.log:
2016-04-20 10:40:04,253 http-bio-8095-exec-21 DEBUG [crowd.manager.authentication.TokenAuthenticationManagerImpl$TokenValidationFailure] Existing token 'eFs5TeJWunW5092ILwdQ00' for user 'charlie' does not match new token 'QX3ad84d58X3QoUlDe6Lcw00' with validation factors 'ValidationFactor[remote_address=PROXY_IP_ADDRESS], ValidationFactor[X-Forwarded-For=NEW_IP_ADDRESS]'
Trusted proxies have already been configured following this guide: Debugging SSO in environments with Proxy Servers
If you have not configured trusted proxy servers following the KB above, try following the article to check if it resolves your issue.
- When accessing the Application behind only one proxy, SSO works properly.
- In Crowd, go to 'Administration' -> 'Logging & Profiling'. Change the
com.atlassian.crowdpackage to DEBUG.
- Log into one of the applications, and then try going to another application with the same user to see if SSO works
Look at the debug logs to compare the validation factors of each attempted login. For example, in the following logs we compared a user logging into JIRA, and then going to Confluence on a new tab from the same computer:
2016-04-22 01:30:45,917 http-bio-8095-exec-5 DEBUG [plugin.rest.filter.BasicApplicationAuthenticationFilter] Application 'jira' authenticated successfully ... 2016-04-22 01:30:45,918 http-bio-8095-exec-5 DEBUG [manager.token.factory.TokenKeyGeneratorImpl] Generating Token for principal: charlie ... 2016-04-22 01:30:45,918 http-bio-8095-exec-5 DEBUG [crowd.manager.token.RecoveryModeAwareTokenAuthenticationManager] Current Validation Factors: ValidationFactor[remote_address=PROXY_IP_ADDRESS], ValidationFactor[X-Forwarded-For=188.8.131.52]
Here, we see that the 'charlie' user tries to login to JIRA through SSO, and the X-Forwarded-For address is 184.108.40.206.
2016-04-22 01:33:00,292 http-bio-8095-exec-15 DEBUG [plugin.rest.filter.BasicApplicationAuthenticationFilter] Application 'confluence' authenticated successfully ... 2016-04-22 01:33:00,294 http-bio-8095-exec-15 DEBUG [manager.token.factory.TokenKeyGeneratorImpl] Generating Token for principal: charlie ... 2016-04-22 01:33:00,294 http-bio-8095-exec-15 DEBUG [crowd.manager.token.RecoveryModeAwareTokenAuthenticationManager] Current Validation Factors: ValidationFactor[remote_address=PROXY_IP_ADDRESS], ValidationFactor[X-Forwarded-For=220.127.116.11]
In this log, we see that 'charlie' goes to Confluence and tries to generate a token, and the X-Forwarded-For address is now changed to 18.104.22.168. Since 'charlie' is accessing both applications through the same machine, his IP address should remain the same. In this case, the first proxy is generating a new IP address each time the user sends out a request.
When a user first logs into Crowd, the application generates a token for the user with validation factors. The validation factors above include a remote_address (which is the IP address of the proxy), and X-Forwarded-For address (which should be client/user's original IP address). When a user tries going to another application, Crowd tries to validate that token with the original X-Forwarded-For address. As long as the remote_address is in your trusted proxy settings, Crowd will not expect these IPs to be the same. Since one of the proxies is generating a new IP each time the user tries to access, Crowd thinks that these requests are coming from two different IPs, even though they are both coming from the same user on the same machine.
Check that the proxy is setup properly, and that it does not generate a new IP for each request.
Depending on the proxy, you should be able to configure it to forward the original client's IP address, which should be static. The proxy will need to pass the user's actual IP as X-Forwarded-For, not the newly generated IP for Crowd to validate these tokens and for SSO to work. The following are examples on how to do this depending on your proxy type:
In general, check that your X-Forwarded-For headers have been configured properly