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.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Jason,
Were you able to resolve this? We are seeing the same problem.
Thanks
-Mahadevan
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.