a port for user authentication Confluence --> JIRA

[SEBtheSaviour]

I have a JIRA installlation with internal user management.
I set up it for LDAP auth for users, however, I have a Confluence installation which uses a JIRA server.

The problem is that if I set up a JIRA behind a firewall the communication seems to be broken while I cannot find the exact cause. 
The symptoms are that users cannot log into a Confluence when JIRA is set up in this way.


I've tried to set up the TCPDUMP in order to find flows between the JIRA/Confluense for user auth, it does nothing.

does anyone can help me to solve this:

• what ports are commonly used between JIRA and Confluence (with no separate CROWD) to user auth?
• if there's something else if users are LDAP'ed? 
• from my perspective this situation is not occuring when I set up JIRA and Confluence with no Jira behind a firewall, while I can't really see what ports are used and if these are kinda "dynamically assigned" or just static.
• I know that CROWD uses a port but I've tested this and it seems to be not as my case.

Somebody/Someone has a similar issue?

Thank you in advance!

[SEBtheSaviour · Accepted solution]

OK, I did it.

Basically with the configuration:

• a custom LB/WAF
• 2 JIRA app nodes

it's doable to talk to Confluence behind a custom LB.

With the standard - proxied conf, the front of JIRA can be hidden behind, but still - there's a separate haproxy with a SSL set up is needed for the applinks at least. 

avoiding of the "internal HaProxy" is not resolvable until Tomcats are configured for SSL, however - as I wanted to skip the SSL termination within the JIRA - I left the HaProxy over internal IP's.

Funny thing is that even adding to the /etc/hosts for each Confluence nodes

10.0.0.2 jira.domain.com
10.0.0.3 jira.domain.com 

is not going to work because of lack 443/SSL in Tomcat so the applinks fails in this way too.

I've ended up with
10.0.0.3 jira.domain.com #HaProxy set up with SSL 

for each of Confluence nodes in /etc/hosts what solves me the issue for now.

[Radek Dostál]

Seb,

This is just a beautiful word salad with no head and toes. I love it. Let's dissect this..

I have a JIRA installlation with internal user management.
I set up it for LDAP auth for users, however

What you have is an external user directory based on LDAP. Depending on the order of the user directories, the users will be authenticated top to bottom depending on where they exist.

E.g. 1 - LDAP; 2 - Internal User Directory

If a user tries to log in, it will first check if they exist in LDAP, if they do, validate the password against LDAP. If they do not exist in LDAP, check if they exist in Internal User Directory, if they do, validate the password against the password stored in Jira, otherwise, tell the user they can't log in, since they have no account in any directory.

I have a Confluence installation which uses a JIRA server.

I think you mean to say that both Confluence and Jira are installed on the same server.

The problem is that if I set up a JIRA behind a firewall the communication seems to be broken while I cannot find the exact cause. 
The symptoms are that users cannot log into a Confluence when JIRA is set up in this way.

This is the main part of the salad.

Both Jira & Confluence are tomcat processes. The tomcat port they run on is defined in conf/server.xml; and they need to be different ports of course if they both run on the same machine.

Whether users can log into a tool is too generic of a statement to make any guesses about. Either, the connection to LDAP is firewall'd, in which case you must allow outgoing connection to that ldap server/post; or, this has nothing to do with firewall to begin with. Either way, if LDAP is in use, do make sure that both tools can actually reach it.

I've tried to set up the TCPDUMP in order to find flows between the JIRA/Confluense for user auth, it does nothing.

Yes, because they're standalone apps. They don't give a single donut who logs into which app. There is no communication between them unless you integrate them, such as via application links. Even then auth is unholy to either of them, they will just exchange applink-authenticated http requests between one another.

• what ports are commonly used between JIRA and Confluence (with no separate CROWD) to user auth?

There is no between. Again, neither app gives a donut about the other one. There is no port. You authenticate over http/s, if you can access a web app over http/s, that's it. Whether that app requires to reach any kind of ldap servers is another matter.

At the end of the day, we can't tell you what you did or what to do. Firewall is kinda out of scope, it might help if you describe in detail what exact configuration you're running on that host, which firewall service, how it's set up, how the atlassian apps are set up, if there is any reverse proxy, etc. All in all I mean a lot of network-related data.

Either way we can though agree it's some kind of configuration issue. Both apps can run on the same host without any trouble and often times do exist installed on the same host out in the world.

[SEBtheSaviour]

Hey @Radek Dostál thanx for reply to this topic :)

I thought it was kinda clear, my bad :)

My infrastructure is:

• separate two nodes of a Confluence --> behind a separate HaProxy :)
• separate two nodes of a JIRA ---> behind a separate HaProxy :)
• + NFS replicated for each one APP but I'll skip this :)

All I want is to set up some custom LB instead of HaProxy for JIRA on the front, but if the Jira works well itself, I cannot do a succesfull communication between JIRA & Confluence, even by disabling a firewall :)

So that's why I'm asking of "what's ports are used" :)

You gave me a good tip to dig into the communication protocol but used between JIRA and Confluence, thanks. I'll follow this path.

I was like "if Confluence uses JIRA for user server - then the auth process should be going on the common 443 port". 

[Radek Dostál]

Yup, completely standalone apps.

If you do end up integrating them together, they will talk to each other over http (where you define the fully qualified domain, with port/context if necessary), that's the only communication they do with one another, and it has to be configured inside the tools.