Cannot get Confluence SSO with Crowd to work
Asked by Philip Colmer:

I have Confluence 4.3.7 and Crowd 2.5.3 on separate servers. I have configured a Confluence application on Crowd, and configured Confluence to use it. I can successfully log onto Confluence with a username and password stored in Crowd.

So everything is fine until I try to implement the SSO portion described in [https://confluence.atlassian.com/display/CROWD/Integrating+Crowd+with+Atlassian+Confluence](https://confluence.atlassian.com/display/CROWD/Integrating+Crowd+with+Atlassian+Confluence.).

At that point, attempts to log in with the same username and password that used to work then fails. The log shows this:

2013-02-19 13:46:10,714 WARN \[http-8090-8\] \[atlassian.seraph.auth.DefaultAuthent

icator\] login login : 'philip.colmer@linaro.org' tried to login but they do not

have USE permission or weren't found. Deleting remember me cookie.  
Two observations:

1. When I log in and Confluence is configured for SSO, it does **not** redirect to Crowd. The authentication window is still from Confluence.

2. The documentation linked to above refers to [http://localhost:8095/](http://localhost:8095/,), mentioning only to change the port. However, because I have them on different servers, I changed the URL to be the FQDN for the Crowd server, as well as making it HTTPS.

Any suggestions as to what I should be changing or looking for in logs to try and resolve this?

Many thanks.

Philip


Answers:
author: Philip Colmer
body: The problem turned out to be the application name in the crowd.properties file on the Confluence server. Somewhat annoying that the error gets swallowed up and not logged but correcting that one mistake has got SSO working.


author: RianA
body: Perhaps [this documentation](https://confluence.atlassian.com/display/CROWD/Troubleshooting+SSO+with+Crowd) would help. Some things that is needed to be noted down.
> SSO will only work with applications on the same sub-domain. Why? Crowd uses a cookie to manage SSO and your browser only has access to cookies in the same sub domain, e.g. \*.example.com.

Hope it helps.

comments: author: Philip Colmer
body: Thank you for the suggestion, but it hasn't helped. I can confirm that testing the login on Crowd works for the Confluence application.

I still feel that this is a Confluence issue, probably to do with the crowd.properties file, but I'm not sure. The reason I think it is a Confluence issue is primarily because it isn't redirecting off to Crowd when I try to log in.


author: C. Faysal
body: Hey Philip,

did you tested authentication on crowd for the confluence app with that user?

> 1. When I log in and Confluence is configured for SSO, it does **not** redirect to Crowd. The authentication window is still from Confluence.

this is ok...cause confluence won't redirect you to login somewhere else (crowd) so the login screen will be prompted from confluence. all authentication proceedures will happen behind that if your confluence is configured well.

at this point let me ask if you've set the following file correctly:

confluence/WEB-INF/classes/crowd.properties

also check if the confleunce host able to access the crowd host on the port you specified

as you say https...you may want to check the ssl_{request\|access\|error}.log on your host where crowd is running for any cert related lines...

the SSO Domain config in crowd describes itself.

ex= .domain.tld

will allow all subdomains for host domain.tld

Leave this field empty if you want cookies to be set to the domain that requests are made to.

is Secure SSO Cookie enabled?

comments: author: Philip Colmer
body: Many thanks for the questions.

So to your first point, you are saying that if SSO is enabled, Confluence still takes care of getting the username and password then talking to Crowd behind the scenes? I wanted to check that because that isn't how I've experienced SSO before. A good example is Google with Crowd - Google redirects off to Crowd, Crowd validates you and redirects back.

I can entirely believe that I've got crowd.properties wrong ... but it hinges on whether or not I should have left the URLs as referencing localhost or if I did the right thing by changing them to full-qualified URLs. Apart from that, I \*think\* I've got the properties file correct.

Confluence \*is\* able to talk to the Crowd server (over HTTPS) for synchronisation so I believe that part of the puzzle is working OK.

I cannot see anything in the logs that suggests that Confluence is trying to talk to Crowd and failing.

Secure SSO Cookie is not enabled.

Thank you :-)


author: C. Faysal
body: exactly. the crowd.properties file thats for confluence should contain the fqdn to the crowd host.

how is it set on the crowd host itself?

i remeber this is located in crowd-home directory

i.e. /var/atlassian/application-data/crowd-home/crowd.properties

mine looks like

```
crowd.server.url=https\://&lt;$host&gt;/crowd/services/application.login.url=https\://&lt;$host&gt;/crowd
```


author: Philip Colmer
body: Mine matches - FQDN entry for \<$host\> and :8443 as the port but otherwise the same.


author: C. Faysal
body: so it is something similar to this Question?

[https://answers.atlassian.com/questions/111499/sso-not-working](/questions/111499/sso-not-working)

you say you can login as user "philip.colmer@linaro.org" at confluence right?

that requires that the user has permission to the confluence application in crowd.

also the order of user directories should not matter...if internal dir is the first to check or not.

i faced some issues with sso too...when i was playing arround with the subdomains on our hosts

my sso domain in crowd is set to ".domain.tld"

i had to clear browser cache and cookies to get sso back to work as expected.


author: Philip Colmer
body: Yes - same symptoms except this is not an upgraded scenario. The installations of Crowd and Confluence are both new.

I will try your suggestion of clearing the cache and cookies and report back.

Thanks.


author: BernardoA
body: Hello There,

I think it'll be necessary to check your confluence log first, if that's the case I suggest you to create a support ticket for a better investigation.

comments: author: Philip Colmer
body: Thanks - support ticket raised as I couldn't find anything in the log that suggested an issue.


Tags: crowd

sso