Hi,
I have my service desk with a proxy which change the domain name. Before we use this, customers can access to the knowledge base with Crowd and the SSO.
Now, they have to reconnect on confluence. When I look to the log, there is a problem of cross domain. I look to the logs and i see a cross domain problem.
How can we fix that ?
Thanks
My understanding is that after you added the reverse-proxy to the picture, the domain name of your applications do not match the Crowd SSO domain name that is configured in Crowd's console (as of today Crowd SSO actually relies upon a shared domain name, according to this feature request this should soon change in a future version of Crowd).
You need to add a rule at the reverse-proxy level in order to change the domain name of the cookies sent by your browser into the domain name that is expected by Crowd SSO.
For instance, in Apache you have to use the ProxyPassReverseCookieDomain directive:
ProxyPassReverseCookieDomain .rp.company.com .internalsso.company.net
Hi,
Thanks for your answer, I have a question : we have to add the ProxyPassReverseCookieDomain on the apache which run Crowd ?
Thanks again
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you share a bit more information about your environment please? What are the URLs of your applications? Where are they accessed from? (intranet/internet) Are they installed on the same server? What is the SSO domain name that you configured in Crowd's console?
The ProxyPassReverseCookieDomain directive will help you in the following situation:
Do you actually have a similar situation?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes of course.
The url of my application on the internet (of course there are some alias but that explain my configuration):
JIRA and Confluence shared the same server but there are a apache server for each.
We doesn't configure a domain in Crowd's console.
I'm not sure that I have the same problem. We want to have SSO from https://www.mfse.fr to https://KIT.fr/confluence if it possible.
Thanks,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @valerian Baillet. Now I understand.
Like I said, as of today, Crowd SSO relies upon a domain cookie, that means that you cannot have SSO between KIT.fr and mfse.fr as the domain names are different. This should change soon, as Crowd's development team is currently implementing cross-domain SSO. According to that post, cross domain SSO should be available in Crowd v3.4.
In the meantime, you can have
As a side note, please note that your current SSO configuration (on KIT.fr) works because Jira and Confluence are installed on the same server. If they weren't on the same server, you would need to explicitly configure (in Crowd's settings) an internal domain name shared by Jira and Confluence. And thus you would also need to implement the ProxyPassReverseCookieDomain directive in your reverse-proxy if you also wanted to have SSO between https://www.mfse.fr/jira and https://www.mfse.fr/confluence
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, I understood, thank you it is very clear.
I think that I can pass my confluence on this url : https://www.mfse.fr/confluence.
So if I want to have my SSO between https://www.mfse.fr/jira/ and https://www.mfse.fr/confluence, I have to implement the ProxyPassReverseCookieDomain in my reverse-proxy with the following configuration :
ProxyPassReverseCookieDomain .mfse.fr/ .KIT.fr
Am I right ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well, the ProxyPassReverseCookieDomain directive should not even be necessary here as from your Apache reverse-proxy perspective, your two applications are on the same server (kit.fr). So the reverse-proxy will automatically transform www.mfse.fr cookies into kit.fr cookies (and vice versa) and we know that SSO already works on kit.fr so that should be all right.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yeah, for the JIRA agents, I have the SSO, but when customers try a search in our portal and select an article, they have to connect on our Confluence server, because the jira is connecting to confluence with the old url.
Does I need to connect JIRA and Confluence with the new url ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry I hadn't figured out that you had an application link between Jira and Confluence. Since in the end Jira and Confluence are on the same server, maybe you should consider creating an unproxied application link as detailed in Atlassian's documentation: https://confluence.atlassian.com/kb/how-to-create-an-unproxied-application-link-719095740.html That sounds like the best option to me but I suggest that you asked Atlassian support for advice about the best option for application links in a double reverse-proxy environment like yours.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.