Not possible to link wiki and jira if 2FA is enabled for user

[Dmitriy Egorov]

Dear Support,

We installed de.syracom.jira.plugins.securelogin version 1.1 to trial with Jira and Confluence.

If 2FA using the plugin is enabled for logged user, it is not possible to link wiki and jira. If I disable 2FA for the user, he is able to create new links between Wiki and JIRA and see already created links correctly.

How it can be fixed, please advice. Thank you in advance.

[Benjamin Heidelmeier]

Were you able to solve this issue? I am currently testing with Confluence 6.12.1 and Jira 7.12.3. Confluence fetches its users from the Jira instance (local user directory there), so they have a shared user base. Application link is configured correctly. The issue occurs regardless whether we tick "shard set of users" in the linking process. The user has registered for Secure Login in Jira and Confluence. The issue already occurs when only Jira has 2FA enabled. Context whitelist is "/download/,/rest/".

When 2FA is not activated for Jira, then issue linking works as expected.

[Alexander Kueken]

Dear @Benjamin Heidelmeier,

you also configured the "application link" whitelist setting in the Secure Login configuration? In the Confluence settings, you have to configure the Jira IP address and vise-versa.

With kind regards,
Alexander Küken

[Benjamin Heidelmeier]

Yes, thanks to your support team I was able to resolve this problem by adding the Confluence server IP to the Secure Login Whitelist in Jira.

[Milan Chheda [INFOSYSTA]]

I am facing exactly this same problem. Can you guide me on how and what IP addresses did you add in whilelist?

Problem: I am unable to add JIRA macro in Confluence pages. It's throwing an error. This error gets resolved when I disable the 2FA. 

I have JIRA & Confluence hosted on same server and on URL having different context. 

https://abc.something.com/jira and https://abc.something.com/confluence 

2FA is working perfectly fine on both the products but is giving errors when JIRA & Confluence try to integrate with each other. 

In the 'Application links' field provided on the configuration screen, should I add IP of Web Server, App Server or Firewall? or all of them?

[Alexander Kueken]

Dear Milan,

Thank you for your request. To allow the confluence macro to communicate with Jira, you have to add the IP of your Confluence server to the "Application links" configuration in Secure Login for Jira. That way, Secure Login knows, that all requests from Confluence are whitelisted and the macro should work as expected.

But depending on your network configuration, this could not be enough to make it work as expected. An HTTP request always contains the IP address of the communication partner raising the request. In your case, Confluence is raising the request, and so it contains the IP address of your Confluence instance. But this only applies, if your Jira and Confluence instances communicate directly with each other.

If the two systems do not communicate directly with each other, and the request is going through any other network instance, like a NAT interface, a proxy server, firewall or any different kind of security appliance, the request does not contain the IP of Confluence as sender, but instead the IP of that additional instance. So if you have a proxy in place, the request includes the IP of the proxy, instead.

To make the switch of the sender transparent to the receiver, the request could or should contain a forward header. This header contains the information, which IP was the original sender of the request. Sadly there are two problems with this header:

• The name of this header is not standardized. Each manufacturer of network components can decide to choose his own name for this header field. Secure Login by default checks, if the most common name "X-Forwarded-For" is used. But you can define the header name on your own, by setting the "Forward Header" option accordingly in the Secure Login configuration. If this field exists, Secure Login extracts the IP of the original sender from it and uses it for the IP check.
• Not all proxies, firewalls, and so on, include the forward header by default and you have to activate it first.

One important security hint: If you use a proxy or something similar, please do not add the IP of it to the "application link" or "ip whitelist" configuration, because then, all requests would be whitelisted and Secure Login would be useless.
I hope this information helps, to resolve the issue, you are experiencing. If not, please add de.syracom with log level DEBUG to the log configuration of Jira and Confluence, reproduce the error and generate a support ZIP in both systems. Afterward, raise a support ticket at our Service Desk and attach the support ZIPs to it so that we can take a more in-depth look into it.

With kind regards,
Alexander Küken

[Milan Chheda [INFOSYSTA]]

Thanks @Alexander Kueken for the quick reply. Appreciate it.

Question on X-Forwarded-For. If we add that, we will receive the submitter IP address, which will be different for each user, right? So how I can use that in IP Whitelist?

And yes, you are right, JIRA & Confluence do not communicate directly. The request goes to firewall, which sends to the reverseProxy and then it goes to the application server. But we can't add web servers IP address that is used for reverseProxy because all requests would get whitelisted. 

Can we use Context Whitelist (URL Filter) in this case somehow?

[Milan Chheda [INFOSYSTA]]

I was able to resolve this issue by adding the APP server IP in 'Application Links' >> IP Filter. 

That worked for me. Now, jira macro as well as 2FA, both are working perfectly fine. 

Thanks @Alexander Kueken for your help as well as detailed explanation. 

[Alexander Kueken]

Dear Dmitriy,

as in your other question, can you provide us with a few additional informations please? If you do not want them to write here, please write me to our support address and I will take care, one of our developers will take a look in your issues:

• Which version of JIRA and Confluence you are using?
• Does JIRA and Confluence use their own user management or do you use some central user management, like LDAP, Microsoft AD or a Crowd Instance?
• The application links between JIRA and Confluence are configured correctly?
• Does the user have registered for Secure Login both in JIRA and Confluence?
• You made changes to the context whitelist parameter in the Secure Login configuration, or do you use the default values?

best regards,

Alexander

[Dmitriy Egorov]

Dear Alexander,

I sent mail message to 'SecureLogin.JIRA@syracom.de' with requested details and additional questions.

Rerards,

Dmitry Egorov

[Dmitriy Egorov]

Dear Alexander, Support Team, I sent all requested details and additional questions to your team by email some days ago, but still no any updates. And our trial will expire tomorrow (25/Nov/16 ). Could you help to extend the trial for one month. We need additional time to make a final decision. Thank you in advance.

[Alexander Kueken]

Dear Dimitry,

I will answer your mail during the day. Please give me a few hours. And do not worry, you can extent the trial for another month. Everything later by mail.

Regards,
Alexander 

[Dmitriy Egorov]

Dear Alexander, thank you, I will wait.

[Dmitriy Egorov]

Dear Alexander,

Please don't forget to send me details to extent the trial. Tomorrow the plugins for (JIRA & Confluence) will stop working.

Thank you in advance

Regards,

Dmitry Egorov