Shibboleth, Apache and Application Links - can't work together?

Jason Orlando [Dow Jones] July 15, 2014

Hello, I've been searching (fruitlessly) for a way to implement the following requirements:

JIRA and Confluence using Apache Reverse Proxy

JIRA and Confluence using Shibboleth SSO for user requests

JIRA and Confluence Application Links working properly

The root of my problem seems to be that app links require use of the BASE URL, which in my case would be a Shibboleth Protected URL. I've been attempting to open up other ports, either directly in Tomcat or through Apache Reverse Proxy, and those ports work fine if I hit them directly with a browser, but Application Links cannot be configured with these ports (it simply overwrites them with the base URL while creating the link).

In summary, I can get Applinks + reverse proxy working, or Shibboleth and reverse proxy working, but it seems impossible to get them all working simultaneously. IF anyone has this working, i'd appreciate some general advice on how to set it up. To be clear: all communication between JIRA and confluence using Applinks should not be protected by shibboleth. Because of this i've been attempting to set up a separate virtual host in apache to handle this communication. The problem is that we need to make all of this traffic hit the application via the BASE URL.

3 answers

0 votes
Mahadevan Kattie November 10, 2014

Thanks Jason.  We would need to have the login URL set to shibboleth.

Did you use the HTTP remote authenticator plugin in JIRA? We tried to add a second virtual host but the plugin redirects to Shibboleth when setting up an application link. Not quite sure at this point how we could bypass the redirect.

Jason Orlando [Dow Jones] January 21, 2015

Sorry for the delayed response.  I used IPTables to ensure that any traffic from the confluence server is redirected to a different apache virtual host port which is not shibboleth protected. 

0 votes
Jason Orlando [Dow Jones] November 10, 2014

I worked around the issue (For now) by not requiring a shibboleth session for access against the base JIRA url.  This allows users to direct login to JIRA using the dashboard login gadget, or they can click the login link which goes to our IDP.    My other solution to this issue was to set up a second virtual host (which was not shibboleth protected) and use IPTables to reroute any traffic from the confluence server which was inbound for 80/443.   I also found that Adaptavist (Atlassian Expert) has a plugin which handles Auth called Umbrella, but i have not installed or tested that software yet.

0 votes
Mahadevan Kattie November 10, 2014

Jason,

Were you able to resolve this? We are seeing the same problem.

Thanks

-Mahadevan

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events