ericsalonen good point, I think the best thing to to do in that case is to raise a feature request for your use-case, it sounds quite different from what the JSD<->Confluence integration was designed around.

Hi Hamish,

Thanks for all the effort mate but unfotunately this is written in the article you linked (providing self help resources for your customers with a knowledge base)

"Note: This setting only opens up the search restrictions for users who do not have the permission to view the space. When they open the Confluence pages by clicking the search results, they still do not get to see the pages due to the lack of the permission. "

So unfortunately it looks like the only thing that can be achieved is the search result but not the actual article as that immediately asks the user to login.

Just seems like this feature is WIP.

Cheers,
Eric

I think it's this issue https://ecosystem.atlassian.net/browse/APL-1310

My memory is a bit hazy, since I last worked on applinks a while back, but based on the article below, the solution is to turn off 3LO

It's a bit unfortunate naming, but both "3LO" and "2LOi" applinks implicitly have 2LO enabled

2LO is what's used for server<-> server communication (no users involved, and therefore no logging-in)
2LOi uses 2LO but with a username attached to the request to impersonate on the remote side
3LO is your classic "please login to authenticate" authentication

"execute as" is implemented using 2LO from memory
using the legacyEdit screen you should be able to turn off outgoing 3LO in Confluence, which should get rid of the "login to confluence" thing

https://confluence.atlassian.com/servicedesk021/providing-self-help-resources-for-your-customers-with-a-knowledge-base-693896351.html

Here is a good description from the guy who implemented "execute as"
https://ecosystem.atlassian.net/browse/APL-1046?focusedCommentId=135371&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-135371

HI Hamish,

Thanks for the reply mate.

I was able to modify the Execute As parameter with the legacy edit mode which actually fixed the problem of actually setting up the KB link to a Confluence space.

However I created a support ticket because it doesnt seem to work for the actual end users as Customers in the portal because it still asks the customer to login to Confluence (which they dont have) - thus the Execute As not working for this feature.

Any chance you recall this bug and if it is reported or not to Atlassian?

Hi ericsalonen OAuth is used for a few different autentication models, but how it's been mainly used for at Atlassian is for performing requests for users on system A as their corresponding user on system B.
In 3LO they're meant to be the same people but with different usernames and in 2LOi they're meant to be the same people with the same usernames.

When the Applinks team (which I was on) removed "execute as", we had no-idea that this functionality depended on it.
Currently the legacyEdit workaround is the best approach for implementing what you want. Hopefully eventually we'll implement a better approach but that's on Jira Service Desk team.

The legacyEdit parameter enables the old configuration page, which provides full access to the old configuration screens, including the "Execute as" option which you need to set it up as you want.

There are currently no plans to eliminate the legacyEdit page, and I strongly doubt we're going to remove it before a better solution is in place

And to XVT Solutions - it seems that what your solution suggests is just setting up an Oauth impersination setup that can already be done with the features available (that is if I understoon correctly that you are just editing the outgoing of Jira auhtentication to Oauth impersination and then in Confluence allowing such impersionation to income and authenticate, meaning you have the same user in both systems, as per your comment).

This problem here is trying to address the problem where the users are completely different in these systems and thus Hamish suggestion needs to be done on the Confluence side so that we can set the "Execute as" parameter in order to access the KB articles when the customer is trying to search for solutions.

Can somebody from Atlassian please explain this issue as to why is there an option for Oauth authentication when it can not be even utilised? Isnt the whole purpose of Oauth that when the 2 applications have different set of users then the request is made using a system user (as in what Execute As did). Correction: this is the case where the customer will not have a confluence account to which they can use to get a Oauth token. My question was in regard to the use case where the customer will not ever have a Confluence account. Or does this mean I should setup Confluence to use Jira as user server?

How do you setup the KB and JSD feature properly with OAauth if Execute As is no longer available? Exactly how are we supposed to use it and what does it do?

If the actual recommendation from Atlassian is to open up the Confluence and space to anonymous usage then why on earth even display the Oauth option? What does it do?

Of course in the cases of the applications having the same set of users you can use Oauth with impersoniation - but what is the use case for just Oauth if anonymous is recommended?

Am I dumb and not understing this correctly or is Atlassian just pissing me off once again?
 

For the record, we (JIRA 7.3.5 with SD 3.4.2 and Confluence 6.1.2) are trying to do the same thing as the original poster, and have run into this exact same issue.

(I arrived here from the page https://community.atlassian.com/t5/JIRA-questions/Integrating-Jira-Service-Desk-and-Confluence/qaq-p/53045)

We too had a system-wide two-way application link with OAuth set up between the two services. 

I subsequently also made a two way app link from our the Confluence Knowledge Base Space to the JIRA Service Desk project... but it didn't seem to do much.

Within the JIRA SD, clicking on the "Knowledge base" icon on the left hand menu brings up a pop-out dialogue box.  Selecting the "Link existing space" button results in an error message saying "We're having trouble communicating with the application. Wait a minute, then try again."

The JIRA catalina.out has messages saying:

[c.a.s.i.api.applink.BaseAppLinkResponseHandler] Applink request has returned an error with status code 401: {"message":"Client must be authenticated to access this resource.","status-code":401}

Anyone else who ends up on this page should be aware, that the workaround mentioned by Hamish Farrant needs to be done on the JIRA server, not on confluence

ie. go to  https://JIRA.YOUR.DOMAIN/plugins/servlet/applinks/listApplicationLinks?legacyEdit=true

The workaround was to edit the app link on Jira, enabling the "Allow user impersonation through 2-Legged OAuth" on the "OAuth" tab, and then going to confluence and changing the Incoming link from "OAuth" to "OAuth (impersonation)".

This seems to have worked.. we can establish a link, and it works for users in Crowd, who are common to both systems.  However, It seems that it may not work for Service Desk customers, as they do not exist within Confluence.  In which case, it seems that we may be forced to enable Anonymous access on confluence globally, and on the KB space.

Andy

This is very important for us.

Otherwise we would have to expose our documentation to everyone, to make the Customers of the Knowledge Base be able to read the documentation.

I've raised this issue to look into finding a better fix for this.

https://bulldog.internal.atlassian.com/browse/SIN-181