Crowd SSO auth fails and requests captcha

[Gaël Marmillod]

Hi everyone !

Newcomer here, 1st time setting up Atlassian products, I've been deploying Core, Service Desk and Confluence successfully in my infrastructure. All are behind an "haproxy" reverse proxy, which handles SSL and redirects to the proper app based on the URL/hostname.

Tinkering with user management to centralize it via Jira Core, I soon though SSO would be a serious plus, so I've deployed Crowd. However, after following config instructions, I seem to be hitting a wall, can't get my setup to work.

I configured Crowd as a "User Directory" for Core/SD/Confluence (and added those apps in Crowd), gave access to various Crowd groups on Core/SD/Confluence and could successfully authenticate with a Crowd account on those (makes me think my base Crowd setup if functional).

However, when I change WEB-INF/classes/seraph-config.xml on Core/SD/Confluence server configs to set it to the SSO authenticator, login never succeeds and adds a captcha.

This shows up in catalina.out (from Jira Core) when a login is attempted:

08-Aug-2018 14:53:05.596 WARNING [http-nio-8080-exec-16] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://<jira core url>/rest/gadget/1.0/login, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

 
As we mean to access the setup remotely and via hostnames, all configs, app and "User Directory" links have been done with hostnames, not private IPs. So the apps/servers talk to each other via the reverse proxy, and this has worked fine up till attempting to set up SSO.

When adding applications in Crowd, I used names with spaces (Jira Core, Jira SD, etc..), so I initially wondered if this would require quotes in crowd.properties, or if it simply would fail. To check, I added an app entry with "jiraconf" name, and changed crowd.properties accordingly for the Jira Core server. Didn't help, so I guess the issue isn't here.

I wonder if I have a "cookie" issue of some sort for SSO. Could the "https to http" transition done by the proxy be the problem ? After login attempts, I do see a "domain" cookie added in my browser.

Ideas ? Pointers ?

Additional details:
- Added IPs in "Trusted Proxy Servers"
- Added IPs and hostnames to Crowd apps "Remote Addresses"
- All hostnames resolve to the same public IP
- Linux/CentOS based setup with latest app versions

Observations:
- when logging off from the Crowd server, I need to manually delete its related browser cookies to successfully re-login. Otherwise I'm stuck to the login page

[Bruno Vincent]

Hello @Gaël Marmillod

Maybe this is some stupid question but if I assume that your applications URLs are like 'https://jirasd.yourdomain.com', 'https://jiracore.yourdomain.com' and so on, did you set up 'yourdomain.com' as your Crowd SSO domain in Crowd's configuration?

Another question: do you have an external domain and an internal domain? (I mean 'https://jirasd.yourdomain.com' as the public URL and 'http://jirasd.internal.com' in your HAProxy rules).

[Gaël Marmillod]

Hi @Bruno Vincent

Thanks for getting involved !

This is correct, I am accessing the applications via "https://jc.mydomain.bla" like URLs, which have been set as base URLs in the apps.

The Crowd SSO domain has indeed been set with "mydomain.bla" in Crowd config.

I didn't use an internal domain, as there won't be internal access. HA proxy redirects to private IPs and ports.

This makes me wonder if maybe I should explicitly set the "cookie.domain" attribute in my apps' crowd.config files ?

[Bruno Vincent]

Well, my guess is that the root cause of the issue you're facing here is that the Crowd SSO cookie is not forwarded to your applications with the right domain name (mydomain.bla) since you're using private IPs instead of FQDNs in your HA proxy config (maybe it's not forwarded at all).

I don't think that overriding the cookie.domain property in the applications' crowd.properties files will work here as from your HAProxy's perspective it sends HTTP requests to URLs like http://192.168.0.1:8080/ and should not allow a Set-Cookie response on mydomain.bla. You might want to give it a try though.

According to me, the right way to handle reverse-proxies situations like this is to use FQDNs. So your browser sends requests to https://jira.mydomain.bla and your HAProxy sends that very same request to http://jira.internal.bla. In that case, your Crowd SSO server is configured for the internal.bla SSO domain and your HAProxy must change mydomain.bla cookies into internal.bla cookies (and vice versa). I'm not very familiar with HAProxy but in Apache you have to use the ProxyPassReverseCookieDomain directive for this.

[Gaël Marmillod]

Thanks a lot for the additional input !

I've been exploring and tinkering quite a bit more, but haven't yet managed to get SSO working.

Looks like HAproxy is the least documented proxy option in Atlassian docs and KBs, so I've been searching how to translate configs.

I also worked towards using an internal domain instead of IPs, but it seems I didn't choose an appropriate one, as Crowd won't accept it as the SSO domain (I assume it's because it ends with .lab).

I now pointed my apps directly at the Crowd server so that they do not talk via the reverse proxy anymore, also using hostnames instead of IPs. Everything keeps working fine as long as I don't enable SSO authentication.

I think I'll try and involve support at this point, hopefully they can give some more insights and point me in the right direction.

[Yuriy Lozhkin]

Hi @Gaël Marmillod 

I have exactly the same problem

Tell me please, did you manage to solve it?

[Gaël Marmillod]

Hi @Yuriy Lozhkin 

Right on, seems I didn't give an update here.

Been a while now, so hopefully I remember it right. In the end, the solution was (as it sometimes is) dead simple.

At some point, I clearly had mixed up  some passwords. Wanting to do things by the book, I had different accounts and password for all servers and apps, at pretty much every level (root, web admin, database, etc...)

Long things short, I had the proper "application name" and "password" defined in Core/SD/Confluence via the web GUI, matching Crowd configs at the other end. So the centralized authentation would work in non-SSO mode.

But the password I set in crowd.properties was different. I checked the crowd.properties a dozen times, but never though to challenge the ones set at GUI level (which aren't visible). So, following Atlassian Support's suggestion, I explicitly re-entered the password everywhere, and then everything worked as expected.

Let me know if that helped !